Security Identifier (SID) to User Identifier (uid) Resolution
System
Luke Kenneth Casson Leighton
lkcl at samba.org
Tue Jan 4 18:56:33 GMT 2000
On Tue, 4 Jan 2000, Cole, Timothy D. wrote:
> > -----Original Message-----
> > From: Luke Kenneth Casson Leighton [SMTP:lkcl at samba.org]
> > 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
> now...
well... not really. :-)
tim, do you want to implement a libsurs.a / libsures.so? two functions:
CREDS_POSIX
{
union
{
gid_t
uid_t
}
}
CREDS_NT
{
DOM_SID sid;
}
int surs_posix2nt(CREDS_NT *nt, CREDS_POSIx *posix)
int surs_nt2posix(CREDS_NT *nt, CREDS_POSIx *posix)
a file /etc/surs.conf should contain the "automap" stuff in it.
More information about the samba-technical
mailing list