generic ACL interface (RFC)
Cole, Timothy D.
timothy_d_cole at md.northgrum.com
Wed Jul 28 20:35:38 GMT 1999
> -----Original Message-----
> From: Luke Kenneth Casson Leighton [SMTP:lkcl at switchboard.net]
> Sent: Wednesday, July 28, 1999 14:08
> To: Multiple recipients of list SAMBA-TECHNICAL
> Subject: RE: generic ACL interface (RFC)
> > > a mapping (not necessarily a good one) to unix
> > > permissions.
> > >
> > That's (typically) accomplished by the native ACL implementations
> > themselves.
I was mainly indicating that the native ACL implementations all
(with perhaps the exception of AFS) provide precise mappings (first three
[fixed] ACEs) to Unix permissions themselves; most of the Samba ACL
"backends" won't need to concern themselves with explicitly mapping unix
permissions as a result.
(The ones that don't map back to the unix permissions (i.e. AFS)
ignore the Unix permissions anyway)
> so, if the HP/UX ACL implementation supports something nice (which someone
> mentioned that it did, which posix does not) then we can map it to an NT
> ACE or whatever.
Not always. Some HP ACEs simply cannot be mapped into NT ACEs at
all -- among others, those that contain both a user and a group
specification. There are also things like the POSIX "mask" ACE type.
(although for that, it might be conceivable to create a bogus user/SID for
"acl-mask" or similar)
> > Rather than implementing NT ACLs on Unix per se (that's a slightly
> > different problem),
> i'd suggest avoiding this. no-one is allowed to suggest maintaining a
> separate database with ACL permissions on a per-file basis, ok? :-) we've
> discussed this before (two-three years ago) - you risk losing info.
Yick; indeed. Another problem is that in implementing something
like that, Samba suddenly becomes responsible for enforcing permissions,
instead of the OS. Samba was not designed for that -- it'd be extremely
hard to secure everything, and the necessary wrapping of everything in
explicit checks wouldn't help performance either.
> remember UMSDOS?
I think that worked reasonably well for what it was intended,
primarily (only?) because the DOS side of things _usually_ had little reason
to touch the files.
More information about the samba-technical