NT/Unix ACLs

[Cole, Timothy D.]

> -----Original Message-----
> From:	Matthias Wächter [SMTP:matthias at waechter.wol.at]
> Sent:	Friday, July 23, 1999 5:11
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	NT/Unix ACLs
> 
> Hi!
> 
> I don't want to stop the discussion on what should be in the ACLs to be as
> compatible as possible to NT's ACLs.
> 
	Well, really the representation we're trying to hash out needs to be
general enough to be convertable to and from all of the common ACL
representations without information loss.  The actual interpretation of the
ACLs isn't actually too important at present, I think, as it typically won't
be Samba's responsibility.

> But: Although there is some advantange in using NT's advanced ACLs instead
> of Unix's UGO, I see lot more positive effect in using (something like)  
> the permission scheme known from Novell (3.x, I had never contact to 4.x).
> 
> 1. In a directory called DATA, I can not only set who (user or group) has
> permission on which subdirectory, but can specify who can _see_ the
> directories in the listing of DATA/. This is not possible with NT ACLs.
> 
	It's easy enough to stick a permission bit for that in our ACL
representation, but if the underlying OS doesn't support it, and it can't be
represented to the NT client (thus, the user cannot see or change it), what
would be the point?

> 2. With NT ACLs, specifying access rights, one (the administrator) always
> has to set permission on each and every file in the whole tree. When
> granting additional rights and selecting "(re)set rights in
> subdirectories" using Explorer, the rights of all files and directories
> are set to _exactly_ those specified. Not only this needs a lot of time
> changing permissions for large and deep trees, any specially set ACL for a
> subdirectory or a file located there is reset. Using cacls.exe seems to be
> a better way (one can explicitly grant/revoke additional rights), but
> using a command line tool, we also could change the way ACLs are stored
> and interpreted.
> 
	You mean writing a new tool for manipulating ACLs from an NT client?

> The interesting parts of Netware's ACLs are:
> 
> * the inheritance mask for a directory (don't need to specify access masks
> for every file in the tree)
> 
	This is a property of the server OS.

> * groups in groups (ah yeah, that's what I call group administration!)
> 
	It _is_ nice, but it's not an ACL issue at all.  It's a property of
the server OS.

> * Only directories you have access to can be seen in the tree.
> 
	That might actually be an interesting per-share option for Samba.
i.e. directories you don't have either read or write permission on become
invisible.  (since you couldn't browse into them anyway -- if you had search
permission, you could still access files within them by explicitly
specifying the path)

> * group membership is effective immediately: f.e. a "dir" prior to
> membership may show no directory, a "dir" a few seconds later grants you
> the appropriate access (of course, revoking is the same the other way
> round)
> 
	That's a property of the underlying server OS.

> * ACLs for trees are only stored in one place keeping the ACL database
> small and making changes very quick
> 
	That's also a property of the underlying server OS.

> * the possibility for security holes because of single files forgotten in
> the tree with wrong rights is far less than in NT (of course, in Netware
> one can also shoot himself in the knee)
> 
	This is mostly a property of the client, specifically how
permissions are set.

> Is anybody out there thinking that there is a chance of having best of
> both worlds? I don't want to be pointed to a novell emulator! :-)
> 
	This kind of sounds like a request for Samba-on-netware, to be
honest. :)

	Either most of these things need to be supported/implemented in the
underlying OS, or Samba needs to become an NOS in its own right, with its
own SAM and permissions mechanisms.  Which might or might not be a bad
thing; I dunno.  I'd tend to think that it'd be outside the intended scope
of Samba, though.