ACL / SD support

[Michael Stockman]

Hello,

> john, i think this acl implementation is being considered as an
internal
> samba implementation and won't ever be dropped to disk.  it
therefore
> serves as the interface between NT security descriptors and the
underlying
> filesystem.
>
> exactly why this is being considered, i really don't know,
particularly as
> samba will not be expected to support anything other than NT
security
> descriptors.

I would expect samba to support SUN ACLs/SDs as well as linux ACLs/SDs
when they are available. If the SD is dropped to disk it should be
saved as a native SD (how else?). I don't suppose anyone is suggesting
that we create ".filename.sd" all over. For those SDs that represent
objects internal to samba, we'll of course create a samba native
format (I think this is cleaner than NTs soulution with self contained
SDs that are dumped and expect to recklessly be loaded).

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
implementation (Luke, this would reduce your work).

> i mean, why map to something that's either a subset or a superset of
the
> security model we're trying to implement?  i mean, if it's a subset,
> you're dropping permissions.  if it's a superset, you're wasting
> permissions.

For the time being, I think of it as a superset. We are in fact not
only implementing one security model but must be able to seamlessly
interface with N security models. As I have no clue what someone might
(have) put in an ACL/SD (on any system) I want to be able to store it
in the ACL/SD when I get a clue.

Luke has suggested duplicating VMS/NT SD/ACL, which is what I in
practice am doing (with some modifications). I do refuse to call them
NT SDs/ACLs because thay are not, even if they had exactly the same
format they wouldn't have been.

> and then there's the issue of if it doesn't support SIDs, that's
_two_
> overheads to convert from SIDs to posix and back, if the target
filesystem
> supports SIDs.

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,
there is no conversion needed. The only time you need to convert is
really when writing the ACL to the net (assuming the file system is
uid_t/gid_t based).

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
need to be able to resolv between the two and then you're talking
overhead. I have for the time being chosen uid_t/gid_t.

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.

> i'm not against this effort, i just... don't really get it.  i'm
happy to
> contribute with comments, both critical and supportive.

Please do, I read it all and incorporte what I think is good.
Also, please stop worrying about the SD (it's the easy part), I'll get
to that. I'm just starting with the ACL.
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
with. Actually, I may get the hell part if I write the parsing code
for ACLs/SDs.

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se

Sorry about the length, but I try to give as complete answers as I
can.