This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project. See the Cygwin home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: [HELP] stat(), file permission, r/w access : i'm LOST :(



On Mon, 1 Mar 1999, Larry Hall (RFK Partners, Inc) wrote:
|> Fixing the bug in the source is also possible.  I know Corinna has been 
|> doing some work with making permissions track more closely with UNIX style.
|> I'm not sure whether his changes will help in this arena...

If somebody is going to fix this, I would strongly encourage to fix it
in a way that uses `access' to determine file permissions, not something
based on `stat'.

This would have the benefit of making things work on the AFS filesystem
as well, where using getuid and st_uid (or similar) to determine
accessibility is meaningless: AFS uses ACLs and tokens that determine
access rights, and the application has no way to know either of these
unless it links against the AFS/Kerberos libraries.  Please make the
scheme trust the operating system (or network file system deamons), and
not to build additional logic that fails with ACL-based systems.  For
example, GNU test program has this bug -- it depends on `stat' instead
of `access'. 

Presumably Win32 system calls responds like AFS with ACLs -- call the
right function (`access'?) and it will tell you whether you can access
the file or not.  Alternatively, `stat' should use the security API to
fill in the st_mode fields correctly, but I am not sure this will work
with networked file systems that implement their own security rules.

Cheers,
//lat
--
With sufficient thrust, pigs fly just fine.  However, this is not
necessarily a good idea.  It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead.  --RFC1925, "The Twelve Networking Truths"


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com