Skip Menu |

This queue is for tickets about the Config-IniFiles CPAN distribution.

Report information
The Basics
Id: 84431
Status: resolved
Priority: 0/
Queue: Config-IniFiles

People
Owner: Nobody in particular
Requestors: ragin.jason [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 2.78
Fixed in: (no value)



Subject: SetWriteMode value not being honored when creating new .ini
Perl version 5.8.8 Linux localhost 2.6.18-274.3.1.el5 #1 SMP Tue Sep 6 20:13:52 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux It seems that SetWriteMode() is not being properly honored when executing WriteConfig. I looked into the code some and it appears that $self->{file_mode} is being overwritten in _write_config_to_filename() from the mode of the file created instead of being left alone. Test as follows: $ ./config_inifiles_setwritemode_test.pl $ ls -al tmp.ini -rw-rw-r-- 1 user group 0 Apr 4 10:11 tmp.ini # Should be 600 After patch is applied: $ ./config_inifiles_setwritemode_test.pl $ ls -al tmp.ini -rw------- 1 user group 0 Apr 4 10:12 tmp.ini # 600, as expected The attached patch removes the 2 lines that overwrite $self->{file_mode} and adds error checking to the chmod() call.
Subject: config_inifiles_setwritemode_test.pl
#!/usr/bin/perl use Config::IniFiles; my $cfg = Config::IniFiles->new(); $cfg->SetWriteMode(600); $cfg->WriteConfig("tmp.ini");
Subject: fix_setwritemode.diff
--- IniFiles.pm.orig 2013-04-04 09:03:03.000000000 -0400 +++ IniFiles.pm 2013-04-04 09:22:43.000000000 -0400 @@ -1670,8 +1670,6 @@ #carp "File $filename is not writable. Refusing to write config"; return undef; } - my $mode = (stat $filename)[2]; - $self->{file_mode} = sprintf "%04o", ($mode & 0777); #carp "Using mode $self->{file_mode} for file $file"; } @@ -1711,7 +1709,10 @@ return undef; } if (exists $self->{file_mode}) { - chmod oct($self->{file_mode}), $filename; + my $mode = oct($self->{file_mode}); + if(!chmod $mode, $filename) { + carp "Unable to chmod $filename to $mode"; + } } return 1;
On Thu Apr 04 10:14:30 2013, https://www.google.com/accounts/o8/id?id=AItOawkRWyFLBgr4YXVAA1VOSqQBQlj0eRO7GeM wrote: Show quoted text
> Perl version 5.8.8 > Linux localhost 2.6.18-274.3.1.el5 #1 SMP Tue Sep 6 20:13:52 EDT 2011 > x86_64 x86_64 x86_64 GNU/Linux > > It seems that SetWriteMode() is not being properly honored when > executing WriteConfig. I looked into the code some and it appears that > $self->{file_mode} is being overwritten in _write_config_to_filename() > from the mode of the file created instead of being left alone. Test as > follows: > > $ ./config_inifiles_setwritemode_test.pl > $ ls -al tmp.ini > -rw-rw-r-- 1 user group 0 Apr 4 10:11 tmp.ini # Should be 600 > > After patch is applied: > > $ ./config_inifiles_setwritemode_test.pl > $ ls -al tmp.ini > -rw------- 1 user group 0 Apr 4 10:12 tmp.ini # 600, as expected > > The attached patch removes the 2 lines that overwrite $self-
> >{file_mode} and adds error checking to the chmod() call.
perhaps it was done by design? It is hard to know.
On Tue Nov 21 14:27:15 2017, SHLOMIF wrote: Show quoted text
> On Thu Apr 04 10:14:30 2013, > https://www.google.com/accounts/o8/id?id=AItOawkRWyFLBgr4YXVAA1VOSqQBQlj0eRO7GeM > wrote:
> > Perl version 5.8.8 > > Linux localhost 2.6.18-274.3.1.el5 #1 SMP Tue Sep 6 20:13:52 EDT 2011 > > x86_64 x86_64 x86_64 GNU/Linux > > > > It seems that SetWriteMode() is not being properly honored when > > executing WriteConfig. I looked into the code some and it appears > > that > > $self->{file_mode} is being overwritten in > > _write_config_to_filename() > > from the mode of the file created instead of being left alone. Test > > as > > follows: > > > > $ ./config_inifiles_setwritemode_test.pl > > $ ls -al tmp.ini > > -rw-rw-r-- 1 user group 0 Apr 4 10:11 tmp.ini # Should be 600 > > > > After patch is applied: > > > > $ ./config_inifiles_setwritemode_test.pl > > $ ls -al tmp.ini > > -rw------- 1 user group 0 Apr 4 10:12 tmp.ini # 600, as expected > > > > The attached patch removes the 2 lines that overwrite $self-
> > > {file_mode} and adds error checking to the chmod() call.
> > > perhaps it was done by design? It is hard to know.
Fixed in 3.00003. Thanks!