Security Identifier (SID) to User Identifier (uid) Resolution System

Cole, Timothy D. timothy_d_cole at
Tue Jan 4 18:16:13 GMT 2000

> -----Original Message-----
> From:	Luke Kenneth Casson Leighton [SMTP:lkcl at]
> Sent:	Friday, December 31, 1999 4:58
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	Re: Security Identifier (SID) to User Identifier (uid)
> ResolutionSystem
> john, thx 4 input.
> > > simulate NT ACLs, you mean.  and the mapping between NT ACLs and unix
> > > file/directory permissinos does not depend on the target unix host
> having
> > > ACLs (see above).
> > 
> > It supplies nowhere near the same utility.  Obviously it can be done,
> and is
> > being done, but you are basically limited to the owner and two built in
> > groups, and having to deal with the READONLY bit.
> > 
> > Setting a file READONLY is easy.  Clearing the READONLY bit is
> problematic
> > for a POSIX based security system.  Should it be cleared for just Owner,
> or
> > also for Group and World?
> > 
> > (I do not quite remember what SAMBA actually does in this case.)  The
> > current main VMS port ignores those attributes, and I have not coded a
> > better implementation other than to accurately report the current ones
> for
> > the file.)
> this is an "encapsulated" problem, as part of the "simulation" of NT ACLs,
> using traditional unix file permissions.
> apreciate you bringing this up.
	I should point out (more for the benefit of the list, than yours)
that we aren't really simulating NT ACLs (we can't) -- the ACLs/triads have
the semantics assigned them by the underlying system, rather than NT.
There's no way around that.  

	A system where you actually can store NT ACLs directly and use them
for access control (i.e. the NTFS driver w/ bypass that you mention
frequently) is only a degenerate case.

More information about the samba-technical mailing list