Security Identifier (SID) to User Identifier (uid) ResolutionSystem

[Steve Langasek]

On Mon, 27 Dec 1999, John E. Malmberg wrote:

> Directories on NT are also special cases.  Each ACE has special fields that
> are only meaningful for Directory Objects.  These fields represent what
> permissions that new files created in the directory have.  The default when
> creating the ACE is to have these fields the same as the access fields to
> the directory.

> This default is ok on private shares, but not for public shares.  In this
> case it is usually desirable to remove the permissions for the LANMAN client
> being able to rename or delete a directory, even though they have permission
> to create files in it.

> This could be an interesting issue with Unix where write access implies
> delete access.

If you mean "access to write files in the directory" implies "acces to delete
the directory", then this is not the case, at least on the Unices I work with.
Access to delete a file or directory is controlled by the permissions on the
*parent* directory: even if I own a file, I can't delete it unless I have
write permission to the directory it's in (because unlink() operates on the
inode of the parent directory).

Whether that makes it more or less easy to translate between NT and Unix
semantics, I dunno :)

-Steve Langasek
postmodern programmer