NT file-permissions

[Cole, Timothy D.]

> -----Original Message-----
> From:	Allan Bjorklund [SMTP:allan at umich.edu]
> Sent:	Thursday, July 22, 1999 15:26
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	RE: NT file-permissions
> 
> --On Friday, July 23, 1999, 5:19 AM +1000 Allan Bjorklund
> <allan at umich.edu>
> wrote:
> 
> > --On Friday, July 23, 1999, 5:00 AM +1000 "Cole, Timothy D."
> > <timothy_d_cole at md.northgrum.com> wrote:
> >>	 Anyway, I can already see that the POSIX.6 definition of ACLs isn't
> >> general enough for our purposes; HP-UX's implementation, while
> obviously
> >> influenced by it, will not map to it very well.  vis a vis:
> >     [Description of HP ACLs deleted.]
> >> 
> > 
> >     And AFS has N user and/or group entries (registered with the AFS pts
> > server) with lookup, insert, delete, administer, read, write, and lock
> > permissions applied to directories.  The files in the directories take
> the
> > permissions of the directory. The unix owner/group/other settings are
> > ignored even though they are present.
> 
	So... you'd probably want to disallow changing ACLs on files, but
some sort of ACL should probably be represented for the files nonetheless --
probably the directory's?  All of these permissions, with the exception of
lock, map cleanly to the NT ACLs, so that's not too bad, really.  (POSIX.6
only specifies a _minimum_ of read+write+execute/search(lookup) anyway)

	Actually, delete is a problem, though -- for NT, it's a property of
files, not directories.  You could present it to the NT client on the files,
but you'd have no good way of setting it on the directory.  Hrm... actually
... the "default file permissions" portion of the directory ACL in NT would
be ideal...

> >     Also, my experience tells me that the sticky and execute bits on
> files
> > in AFS may also have an effect, but I haven't found documentation to
> > clarify it.  Some programs pay attention to them, some don't.
> 
	Ugh.  Well... hrm.  My instinct would be that they're mainly used by
the OS when executing programs/scripts.  In which case they could be used to
fill out the execute permission in the file ACLs (since inheriting the
search(lookup) bit from the directory would not make sense).

>     Oh, I forgot, AFS rights are either positive or negative
> (i.e., logical not).
> 
	Fortunately I think NT's ACL representation allows for negative
rights (Jeremy or somebody correct me if I'm wrong), although I'm not really
sure that the shell UI can cope with them -- since you can't set the more
exotic stuff from the shell interface, experience would dictate that Bad
Things are likely to happen if it encountered them :/

	There's still the matter of dealing with ACL entries that can have
user+group pairs; I don't see any obvious way of mapping those to NT.

	Forgetting about at least some of these issues for the moment, I'm
envisioning ACL entrise with the following information (although this may
well be overkill, it's a first crack at being sufficently general to avoid
information loss.  Not all of this information can be presented to the NT
client anyway):

	    - "native" user id (or one of several reserved ids indicating
"owner", "invalid" or "any")
	    - NT id for user
	    - "native" group id (or one of several reserved ids indicating
"owning group", "invalid" or "any")
	    - NT id for group
	    - positive permission set (read, write, execute/search, insert,
delete, lock, set permissions)
	    - negative permission set
	    - default positive permission set (for contained objects)
	    - default negative permission set (for contained objects)

	Note that there may not always be a mapping between the NT id and
the "native" one, or vice versa.  It'd be the responsibility of the
abstraction layer to do the mapping the best it can.  Note that this allows
us to keep track of, say, the owning group of a file -- the "native" group
id would simply indicate "owning group", but the NT id would be that of the
NT equivalent.  Hrm.  I'm wondering if the owner/invalid/any thing would be
better represented by flags, rather than reserved ids...

	When changing permissions, since the transformation to the NT
client's representation is bound to lose information, the "set acl"
operation may need both the original (queried) ACL and the one returned from
the NT client for comparison.  I'm not sure if that should be explicitly
given to it, or to allow the implementation to worry about keeping a copy if
it needs one.