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

Cole, Timothy D. timothy_d_cole at
Tue Jan 4 18:42:11 GMT 2000

> -----Original Message-----
> From:	Luke Kenneth Casson Leighton [SMTP:lkcl at]
> Sent:	Tuesday, January 04, 2000 13:25
> To:	Cole, Timothy D.
> Cc:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	RE: Security Identifier (SID) to User Identifier (uid)
> Resolution System
> > > > > accepts SIDs in ACL set requests. It currently doesn't accepts a
> > > > > non-local SID  in an ACL set request, and I don't think it should.
> > > > 
> > > > i know you don't.  means samba will never be fully nt-domain
> > > > interoperable.
> > > 
> > > Well, in order for Samba to store a non-local SID in an
> > > ACL set it must have some way to store it in the filesystem.
> > > 
> > > POSIX doesn't allow this.
> > > 
> > 	You find or allocate a local "POSIX identity" to use in the ACL, and
> > note (somewhere) its equivalent SID.  Granted, that doesn't help you
> much if
> > you're pulling disks and sticking them in machines with different
> account
> > databases, but that's a problem under POSIX anyway.
> > 
> AGH!  mr cole, what the heck did you have to bring _that_ up for???? :-)
> ok. well, if you took the SURS table with you on the disk, you could get
> away with the uid->SID representation on another POSIX system.
> agreed, the uids would be totally meaningless on the other POSIX system,
> but at least the SIDs would be consistent, as represented from that disk,
> through the SURS table.
	Er, perhaps I should have said "...but that doesn't really matter
because it's just as much of a problem under POSIX anyway, whether or not
you're mapping SIDs."  I didn't intend to suggest it was a problem specific
to using SIDs in this fashion.

	On another note, although it's not really relevent to Samba, over
the holiday I was actually pondering sticking a SURS-like table in a hidden
inode on an ext2/3 filesystem, mapping between uids/gids on the disk and
SIDs.  The kernel patch would also include a SURS-like mapping table
in-kernel, which would map between SIDs and "system" uids/gids (which might
well be different from those on disk).

	The kernel table would be filled out from userspace, having a few
initial entries for root and the like hard-coded.   SIDs with no kernel
entry would map to uid/gid -2 (nobody), until such time as a mapping were
added from userspace.  Mapping between fs uids/gids and "system" uids/gids
would be done by the filesystem driver, so none of the existing interfaces
would really have to change -- no hits from comparing SIDs everywhere, it's
still all word-size integers.

	Of course, one wonders whether or not the gyrations needed to
populate and update such a table from userspace would be worth it, but it
would certainly solve the "disk swapping" problem, even on otherwise
exclusively POSIX systems. ... and I'm really getting off on a tangent

More information about the samba-technical mailing list