NAME

File::Find::Rule::Permissions - rule to match on file permissions and user access

SYNOPSIS

use File::Find::Rule::Permissions;

# Which files can the 'nobody' user read in the current directory?
@readable = File::Find::Rule::Permissions->file()
    ->permissions(isReadable => 1, user => 'nobody')
    ->in('.');
                
# Which files can the 'nobody' user *not* read in the current directory?
@notreadable = File::Find::Rule::Permissions->file()
    ->permissions(isReadable => 0, user => 'nobody')
    ->in('.');
                
# Find big insecurity badness!
@eek = File::Find::Rule::Permissions->permissions(
    isWriteable => 1,
    isExecutable => 1,
    user => 'nobody'
)->in('/web');

DESCRIPTION

An extension for File::Find::Rule to work with file permission bits and determine whether a given user can read, write or execute files.

METHODS

permissions

Takes at least one parameter and up to four. The mandatory parameter must be one of isReadable, isWriteable or isExecutable, which take values of 1 or 0 (actually true or false). Any of those three that are missing are ignored - ie, we match regardless of their truth or falsehood. A value of 1 means that we must only match files where the user can read/write/execute (as appropriate) the file, and a value of 0 means we must only match if the user can NOT read/write/execute the file. To supply none of these three is clearly an error, as it is equivalent to not caring what the permissions are, which is equivalent to seeing if the file exists, which File::Find::Rule already does quite nicely thankyouverymuch.

The 'user' parameter is optional. By default, we check access for the current effective userid, which is normally the user running the program. This can be changed using this parameter, which takes a numeric uid or a username. Note, however, that if the user running the program can't get at parts of the filesystem that the desired user can, the results will be incomplete.

The astute reader will have noticed that File::Find::Rule already handles some of these rules (checking permissions for the effective uid), but not for an arbitrary user. That this module can also check for the effective uid is more of a lucky accident that just falls out of the code when checking for any arbitrary user :-)

BUGS

I assume a Unix-a-like system, both when looking at file permissions, and when divining users' membership of groups. Patches for other systems are welcome.

We divine which groups a user belongs to when the module is loaded. If group membership changes underneath the program, incorrect results may be returned.

There are only minimal tests supplied, as a comprehensive test suite would not only have to run as root, but would also have to go around creating files belonging to all sorts of users with all sorts of permissions. I have tested it myself, but obviously my tests will not take into account all the wrinkles in other peoples' filesystems on other operating systems. Patches welcome.

AUTHOR

David Cantrell <david@cantrell.org.uk>, inspired by a conversation in the london.pm IRC channel and shamelessly based on code by Kate Pugh (FFR::MP3Info) and Richard Clamp.

FEEDBACK

Please! If reporting a bug, please include sufficient information for me to be able to replicate it consistently. Patches are most welcome and will earn not only my undieing gratitude, but also a pint of fine ale. Whilst this is free software, if you wish to show your appreciation by buying something from my wishlist, then your bug reports will go to the front of the queue: http://www.cantrell.org.uk/david/shopping-list/wishlist

COPYRIGHT

Copyright (C) 2003 David Cantrell, in a perlish kind of way. The perl licence terms apply.

SEE ALSO

File::Find::Rule