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

[John E. Malmberg]

> On Fri, 24 Dec 1999, Luke Kenneth Casson Leighton wrote:

> http://www.cb1.com/~lkcl/cifs/draft-lkcl-sidtouidmap-00.txt (and
> .html)
>
> > Quoting the document:
> >
> > >Secondly, the SID S-1-1 represents the concept in the NT Security Model
> > >of "Everyone", and should explicitly be mapped to the Unix "other"
> > >concept.
> >
> > If I understand correctly the NT idea of 'everyone', then this is not an
> > exact mapping.
> >
> > In Unix, if a file (or directory) has permissions of rwx---r-x and is
> > owned by user foo/group bar, then user foo has full access to the file,
> > group bar has  *NO* access to the file, and everyone else has
> > read/execute permissions.
>
> d***.  does that _exclude_ the group bar from accessing the file?
>
> that would be this, then:
>
> foo is granted full control
> bar is denied full control
> Everyone is granted read and execute.
>
> this is different from:
>
> foo is granted full control
> Everyone is granted read and execute.
>
> is that a correct interpretation?
>
> with NT security descriptors, you can do that sort of thing (grant /
> deny).  the order _is_ important.

With windows NT security descriptors, the most restrictive security is the
one that is followed.

To have any access, the user or a group that a user is a member of must have
explicit access granted to it, excepting the following paragraph.

If the user or any group the user is a member of is denied that particular
access, the access is denied.

So under the NT model, any member of group bar has no access to the file in
the above example.

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.


The NT everyone group applies to any user that has access to the box.  All
users authenticated or not are members.  Everyone NO ACCESS means NO ONE has
access to that object, including local system and Administrator.  If the
Everyone group is removed from an Object, then other means to access the
object must be applied.

Yes, you can brain-damage an NT Server by removing the Everyone object from
certain objects with out explicitly adding Local System access.


With NT 4.0 (SP ?) there is an Authenticated Users group that applies to all
users that have had their credentials verified.

The functions of the "root" account are divided between "local system" and
the local administrator.  Of which the local system is the more powerful
one, and the local administrator does not have as much rights (default
configuration).

An as pointed out above, neither has the absolute power of root.

I do not know how ACLs work on those UNIX systems that support them, so I
can not comment on them.

On OpenVMS, if any of the UIC (UID) protections allow access, then that
access is allowed.  If they deny access, then the ACEs on the object are
checked against the Identifiers (NT or Unix secondary group equivalents).

On OpenVMS it can be confusing to the unwary as the order that the user was
granted the identifiers (became a member to the group) and the order that
the ACEs are listed in the ACL matter.

For OpenVMS first match for allow or deny access is followed, all the rest
ignored.  I have not determined how to handle this with SAMBA on OpenVMS.
The Pathworks product just runs it own security handling, so in order to see
what access the LANMAN clients have, you must use the Pathworks
Administrator, not the native operating system utilities.  That is a PITA.


The main case where this becomes a big problem is where you try to use the
facilities on a LANMAN client to change the security on a SAMBA server.

If there is not a uniform implementation of ACLs on the various UNIX
systems, the same issues will be there.

-John
wb8tyw at qsl.net