generic ACL interface (RFC)

[Cole, Timothy D.]

> -----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.