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

John E. Malmberg wb8tyw at qsl.net
Sun Dec 26 20:35:56 GMT 1999


Steve Langasek <vorlon at netexpress.net> wrote:

> On Mon, 27 Dec 1999, John E. Malmberg wrote:
>
> > 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 :)

There is a subtle difference that cound catch the unwary.

If you have write access to the parent directory, so that you can create
files and directories in it, then any subdirectories and files that you have
write access to, you have delete and rename access to also.

This is not the case in Windows NT or OpenVMS.

Take for example the directory tree of:

/public
/public/scratch
/public/projects

If you want someone to be able to put files in /public and in /scratch and
/projects you have to give them write access to all of these directories.

This allows you to rename the project directory.

Since Windows NT has a different permission for write access then delete,
you can protect the permanent subdirectories from these types of accidents.

Otherwise it is frightenly easy with the Windows Explorer shell to rename a
directory, but even easier to drag the "projects" directory tree and put it
in "scratch".

No error message, no warnings.  And then the clueless user calls for a
restore of the missing directory.  And if your operations staff does not
realize what has really happened then your directory tree gets really
polluted.

These type of mistakes do not usually happen in a command shell environment,
or with programmers.  But with a general population of office PC users, you
can count on them.

Please remember though that there is a lot about UNIX security I am ignorant
about though, if I have some of these concepts wrong.

-John
wb8tyw at qsl.net




More information about the samba-technical mailing list