ACL / SD support

Luke Kenneth Casson Leighton lkcl at
Mon Feb 14 21:24:47 GMT 2000

> The intent is to make an API to uniformly work with SDs in samba,
> regardless of the format it is saved in. I think it would be good if
> you wouldn't have to write one samba implementation for each SD

that's unavlidable, michael, which is why i don't understand why you're
going with this alternative impl. to SDs.

> If the target system support SIDs, what type would uid_t be? How would
> we get the SID from the file system? My guess is that a SID filesystem
> have a SURS table and only return uid_t/gid_t to us. In other cases,

the surs table (controlled by sursswitch.conf) is independent of the
filesystem.  it has to be.

> The implementation will have to choose between either SIDs or
> uid_t/gid_t, not both. In case we'd try to put both in, the ACL would

correct.  there's a one-to-one mapping between SID to uid and SID to gid,
therefore you only need  one of them.

> I believe that as long as you don't want to send the ACL to the client
> (use it for access checking) no conversion at all will be necessary. I
> think you both obtain uid and all gids in the session setup, and hope
> you hang on to them. If so, then no conversion is needed there either.

and the NET_USER_INFO3 structure, which contains NT user SID, NT primary
group SID and user's NT groups.
> I see hell for you, Luke, as NT is using the same access bits with
> different meaning depending on which object the ACL is associated

yes.  however, they are consistent.

you do realise that i can't use your code in, say, samrd, lsarpcd and
maybe winregd, don't you?

you do realise i'm still going to need a full, native SD access checking
routine like the one i described last week?

More information about the samba-technical mailing list