Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^2: Inline.pm and untainting

by syphilis (Canon)
on Jul 29, 2009 at 05:10 UTC ( #784129=note: print w/ replies, xml ) Need Help??


in reply to Re: Inline.pm and untainting
in thread Inline.pm and untainting

I'm surprised nobody has answered you yet.

On reflection, the title probably doesn't match the actual question (which boils down to directory permissions) all that well.

So I guess the & 0222 is making sure that each dir is not writable?

Thanks for that - that makes sense (typo - it's 0022, not 0222).

So .... according to stat(), all directories on my windows Vista box (even those that I can't write to) are drwxrwxrwx.
Does this signify some shortcoming of the stat function on Windows ?
Or does it signify some problem with the way this box is set up ?
Or does it mean something else altogether ?

And what are the ramifications re the particular condition in sub env_untaint that's posing the problem ?
I haven't found anything helpful about this in the stat or perlport documentation.

Cheers,
Rob


Comment on Re^2: Inline.pm and untainting
Re^3: Inline.pm and untainting
by afoken (Parson) on Jul 29, 2009 at 07:45 UTC
    So .... according to stat(), all directories on my windows Vista box (even those that I can't write to) are drwxrwxrwx. Does this signify some shortcoming of the stat function on Windows ?

    Yes. Windows uses ACLs, not the Unix idea of owning user, group members, and other people (u,g,o). stat() emulates just enough of the Unix idea to allow common programs to work. It pretends that everything is readable and writeable for everyone. Finding out that things may be read-only or even write-only is left to other functions like open, read, and print. If you would run on a Unix system with ACLs, you would have exactly the same situation. The mode information returned by stat does not know about ACLs, and even if stat() tells you a file or directory is readable or writable for everyone, the ACLs may prevent you from reading or writing.

    Actually, stat() returns some useful information:

    perl -e "printf qq[%08o %s\n],(stat($_))[2],$_ for @ARGV" C:\WINNT C:\ +WINNT\win.ini C:\WINNT\NOTEPAD.EXE c:\WINNT\system32\command.com c:\ +winnt\system32\login.cmd C:\bin\uuencode.pl 00040777 C:\WINNT 00100666 C:\WINNT\win.ini 00100777 C:\WINNT\NOTEPAD.EXE 00100777 c:\WINNT\system32\command.com 00100777 c:\winnt\system32\login.cmd 00100666 C:\bin\uuencode.pl

    (Strawberry Perl 5.10.0)

    As you see, the directory flag is correct, and the X-bit is only set for directories and executables (determinated by the file extension). So, -f, -d, and -x work as expected.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re^3: Inline.pm and untainting
by Just in (Sexton) on Jul 29, 2009 at 08:11 UTC

    I'm surprised that env_untaint was written that way. 0022 as a umask is 755 permission wise which gives the idea that r and x for group members and everyone else actually works for Windows in a Linux/UNIX way.

    Reading stat under perlfunc years ago led me to believe that only a handful of the 13 elements actually worked under Windows. Looking at it now hints that there maybe some cause for doubt - "Not all fields are supported on all filesystem types".

    The concept of group and everyone for Windows does work under domains but not directories, which is why stat returns 0777 even on readonly.

    Shortcoming of stat - I'd say so, but it's not actually since we're given warning. To get directories that you can't write to I'd use Win32::File so

    and not ((stat($_))[2] & 0022)

    becomes

    and ( $attr & READONLY )

    I was going to go through the bitwise & permissions that would yield 0 with 0022, but I actually came on PM to look for something else and now it's home time :p

    Just in

    P.S. your box is fine
      and ( $attr & READONLY )

      That doesn't seem to do quite the same thing. GetAttributes() tells me that neither C:/Windows/System32 nor many of the files in it are READONLY. Yet, I can't write to that directory, or to any of the files in it.

      Cheers,
      Rob

        GetAttributes() (from Win32::File) returns the file attributes that were invented around 1980 for MS-DOS, namely ARCHIVE, DIRECTORY, HIDDEN, READONLY, and SYSTEM, plus three new using the remaining bits of a byte, invented somewhere around Windows 98 or NT 4.0: OFFLINE, COMPRESSED, and TEMPORARY. Again, these attributes do not have any relation to the ACLs. Win32::Security::ACL should be able to access the ACLs and to tell you why you can't write to the directory.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://784129]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (10)
As of 2014-09-22 19:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (198 votes), past polls