perldb.ini permission problem on Windows 11

[PUCKERING]

I'm using Strawberry perl 5.32.1 on Windows 11. Some time ago, on Windows 10 and probably using an older perl, I had set up a .perldb file in my %HOME% folder and added some configuration so that I could automatically use Data::Printer in the debugger. I used to be able to type ::p to get the equivalent of Data::Printer:p output.

Yesterday I noticed that wasn't working. After some experimentation I realized that .perldb wasn't being read at all. Then after some research I renamed it perldb.ini and perl 5.31.1 began reading it. So far so good.

Then came the next problem:

perldb: Must not source insecure rcfile %HOME%/perldb.ini.
        You or the superuser must be the owner, and it must not
        be writable by anyone but its owner.

(It doesn't actually have %HOME% in the message ... I just substituted that in for my username for security purposes.)

Doing what it says sounds easier than it is. So far I've had no luck. I log in with my Microsoft Outlook username, so I managed to change the file ownership to that user with Properties / Security / Advanced. There are three users: my user account, SYSTEM and Administrators. I've changed SYSTEM and Administrators permissions to Deny all access to perldb.ini. My user is the only one with read and write access. Yet that still hasn't resolved the issue. I still get the above message whenever I run perl -d.

I'm stumped! Any suggestions???

[syphilis]

You or the superuser must be the owner, and it must not be writable by anyone but its owner

Seems odd to me that such a very nixy message should appear on a Windows system.
If you have Cygwin or MSYS2, you might like to see what they think the perldb.ini permissions are, and even try using the Cygwin/MSYS2 chmod() function to set the permissions to 0444 or 0644.
Dunno ... maybe that's just a silly idea that has no chance of working at all.

Cheers,
Rob

[PUCKERING]

I tried git chmod. Didn't work.

See my comments below, for an update.

[harangzsolt33]

"You or the superuser must be the owner, and it must not be writable by anyone but its owner."

So, do what it says. Have you tried logging in under the ADMINISTRATOR account and changing the permissions for perldb.ini ?

I recommend that you download a program called "NT Permissions tool" from any file hosting site. This is a single file executable, so it's not a big program that you have to install. On my computer I renamed them to NPTx86.exe and NPTx64.exe and placed them in a directory where they are accessible from anywhere, so I can launch it anytime. These two files are about 700KB each. It's a really handy tool for managing NTFS file permissions for single or multiple files and directories. Without this tool, I am not even sure how else I would have resolved some of my issues. (Earlier I backed up my files to another hard drive, and I tried to open them on another computer, it wouldn't let me. This tool was really helpful!)

Download:
https://www.majorgeeks.com/files/details/ntfs_permissions_tools.html

[PUCKERING]

I tried the tool. Basically, it does what you can do in Properties->Security. Thanks for the suggestion.

See my comments below, for an update.

[NERDVANA]

When you run perl's stat() on it, what do the mode bits show? I agree that Unix permission checks don't make much sense on Win32, but I'm guessing perl will use stat() to check ($uid==0 or $uid==$< ) and !($mode & 0x12). Keep checking those values as you experiment with windows permissions on the file.

[PUCKERING]

Thanks for the suggestion.

See my comments below, for an update.

[PUCKERING]

I dug into the perldb source and found this:

sub is_safe_file {
   my $path = shift;
   stat($path) || return;    # mysteriously vaporized
   my ( $dev, $ino, $mode, $nlink, $uid, $gid ) = stat(_);

   return 0 if $uid != 0 && $uid != $<;
   return 0 if $mode & 022;
   return 1;
} ## end sub is_safe_file

Then I did some experimentation using a test script on the perldb.ini file and determined that (a) the $uid was zero, and (b) the file permission was 0100666.

After some research I discovered that the mode on Windows includes the file type, and that one is supposed to mask it with 07777 in order to get the permissions. The code in the perldb source is not doing that, otherwise the mode would be 0666.

What the test is looking for, though, is a file with 0644. I've tried everything I can in the Properties-Security tab to get that, and no joy. I also tried the tool that was suggested, though it wasn't any easier to understand than the Properties Security tab. Anyway, at this point I managed to get a file that is owned by my userid, and that has no permissions for anyone else -- not even System or Administrators.

Here's what ls -la tells me:

ls -la perldb.ini
-rw-r--r-- 1 jgpuckering 197615 140 Sep 18 11:44 perldb.ini

That looks right, yet when I do a stat on the file I still get 010066:

perl -MFile::stat -E "printf '%%07o', stat('perldb.ini')->mode"
0100666

One thing that is clear is that the perldb test is flawed on Windows. At the very least, it should be masking the mode with 07777 to get rid of the file type.

But beyond that, I think there's something fundamentally wrong with this test. Due to the inherent differences between Windows file security and Unix file security, there seems to be no way -- or at least, no obvious or easy way -- for a user to set the file permissions in Windows so that the file will pass the test.

I suspect that testing file access in this fashion on Windows using stat() simply doesn't work. The test should either be written differently for Windows, or disabled for Windows.

Perhaps this has been fixed in a later release. As I mentioned, I'm running v5.31.1 of Strawberry perl, which is the latest release I can get. I've got a workaround, but this seems to me to be a bug that has broken perldb.ini support on Windows.

Should I report this as a perl bug? If so, how and where?

[syphilis]

sub is_safe_file {
   my $path = shift;
   stat($path) || return;    # mysteriously vaporized
   my ( $dev, $ino, $mode, $nlink, $uid, $gid ) = stat(_);

   return 0 if $uid != 0 && $uid != $<;
   return 0 if $mode & 022;
   return 1;
} ## end sub is_safe_file



On Windows 7, I'm seeing the same result as the OP.
The is_safe_file() sub returns 0, because $mode & 022 returns a true value of 18.
But the leading 0100 is ignored, and the true value of 18 is obtained simply because the 2nd and 5th bits of $mode are true.

This sub has been (in its current form) in perl5db.pl since perl-5.8.8 (maybe even earlier), and its behaviour has remained the same throughout that period.
I know buggerall about perl5db.pl and file permissions, but it feels to me that this sub should not even be called on a Windows system.

I did however find a file named simply "config_data" in a perl (not Strawberry Perl) bin folder of mine for which is_safe_file() returned true.
For that file, the value of $mode, as seen by is_safe_file(), was 33206 (0100444).
If you can set the perldb.ini permissions to that value then you might get lucky ;-)

PUCKERING, if you want to raise an issue about this with the perl developers, then create a "New Issue" at https://github.com/Perl/perl5/issues.

Cheers,
Rob

[PUCKERING]

Thanks Rob.

Your comments jogged my memory. I used to use ActiveState perl. The reason I was fiddling with perldb.ini is that my .perldb file wasn't working. After some experimentation, I realized it wasn't even being read. When I renamed it to perldb.ini it began being read, but with this error message we've been discussing.

But at some point in the past it did work and without that message. That's why it was in my home directory. And so it was probably back when I was using ActiveState perl. My guess is they may have fixed this problem in their code, but that fix never made it into Strawberry perl.

If I find the time I might test that hypothesis by having a peek at the ActiveState perl5db.pl code. And I will definitely post an issue per your suggestion.

[afoken]

It seems Perl (or the C runtime) emulates stat() on Windows. The emulation roughly looks like what a common Unix system returns when an ACL system runs on top of the standard Unix permissions. See also Re^3: Inline.pm and untainting.

sub is_safe_file {
   my $path = shift;
   stat($path) || return;    # mysteriously vaporized
   my ( $dev, $ino, $mode, $nlink, $uid, $gid ) = stat(_);

   return 0 if $uid != 0 && $uid != $<;
   return 0 if $mode & 022;
   return 1;
} ## end sub is_safe_file

This piece of code has no idea of that emulation. Unfortunately, it also has no idea of an ACL system on top of Unix permissions. That should not hurt on Unix, because even with an ACL system on top of the Unix permissions, criticial files should have restrictive Unix permissions. The stat() emulation on Windows has no Unix permissions.

So, is_safe_file() may need to disable the $mode check if $^O eq 'MSWin32'. Perhaps it should also add some Windows-specific ACL tests.

Alexander

[Anonymous Monk]

It seems Perl (or the C runtime) emulates stat() on Windows.

*eyebrow raise*

https://perldoc.perl.org/perlport#stat, stat

https://github.com/Perl/perl5/blob/blead/t/win32/stat.t

https://github.com/Perl/perl5/blob/blead/t/io/fs.t

https://github.com/Perl/perl5/blob/blead/win32/win32.c#l1492

            else {
                char path_buf[MAX_PATH+1];
                sbuf->st_mode = _S_IFREG;

https://metacpan.org/pod/Win32::LongPath

https://metacpan.org/pod/Win32::Unicode

https://metacpan.org/pod/Win32::LongPath

[NERDVANA]

At the very least, it should be masking the mode with 07777 to get rid of the file type.

Well, technically it is. It is masking with octal 022, which is bit 1 and bit 4 (counting from zero) so no other bits are considered. Or in other words "is the world-write bit set?" or "is the group-write bit set?" and if either is set, then the result is true after the bitwise AND operator.

It might be related to the "Everyone" user in Windows? Windows permissions inherit from parent, so I think you'd have to add a new permission for Everyone that explicitly sets "no permission". Disclaimer: I haven't used windows permissions in several years.