ACL vs. ACE

[Nigel Williams]

I made the first point myself in my first reply.  That is why I want to add
the functionality to smbcacls.  Unfortunately I previously used the term ACL
when I meant ACE.  I have experience of ACLs since VMS days and have written
many programs for manipulating ACLs so I do know the distinction even if it
is not apparent in emails.  As you say smbcacls use of ACL at the head of
each ACE to indicate that the ACE is part of the ACL was probably the cause.
Either that or premature senility :-)

Thanks again for your input.

nigel

-----Original Message-----
From: Steven French [mailto:sfrench at us.ibm.com]
Sent: Monday, January 14, 2002 2:59 PM
To: Nigel Williams; samba-technical at samba.org
Cc: Jim McDonough
Subject: RE: ACL vs. ACE


>The syntax of the security descriptor is that used with smbcacls which
>allows multiple ACLs.  So there
>is no need to perform multiple shareadds.


My point was that if you wanted to modify the access control for a share,
it could be awkward using your syntax, because by calling "shareadd" or
"sharesetinfo" it would imply to some that all access control entries would
be replaced by the set of access control entries that you supply on the
command.   In practice this is hard to code in scripts, because to add
permission for a new user to a share, you would have to get a list of all
of the access control entries for the share, then append the new user at
the end of potentially an extremely long list.  smbcacls chose to deal with
this by overloading the behavior by using a flag (-A, -S, etc.) to make the
distinction between replacing all ACEs in an ACL and appending ACEs to an
ACL. Microsoft back in the dark ages chose to deal with this by making a
distinction between the command line options for "Access Add" which created
a new list of user/permission pairs for a resource and "Access Grant" which
appended the new user/permission pairs to the resource.   As you might
expect this also caused lots of confusion and many sleepless nights for IBM
doc writers and support people trying to explain the syntax.

I thought that the command line syntax that IBM later used for similar
tools in which a distinction was made between manipulating the ACL itself
(which is an array of ACEs) and manipulating an ACE (a specific
user/permission entry of the ACL) was reasonable.  Of course there are
worse examples of command line syntax (remember "dcecp" ... the utility for
managing dce).

By the way the terminology of the smbcacls man page seems misleading using
ACL for both ACL and ACE.   The term Access Control Lists (ACLs)
historically has been used to represent the list of access control entries
(ACEs) for a resource not an individual user/permission pairs.   smbcacls
seems to use the term ACL for both ACL and ACE.   The on-line documentation
of the Microsoft cacls utility probably didn't help things by using the
term ACL loosely in one sentence.   Access Control Entries is defined
correctly in the online Microsoft documentation (and is consistent with the
terminology that I have seen before on other servers) i.e. "Access Control
Entry: An entry in an objects DACL that grants permission to a user or
group.  An ACE is also on entry in a objects SACL ... Access Control Entry
is also called ACE."

The ACL itself (which was often part of the file or directory meta-data)
held little information just the owner of the resource, the auditing flag
and a pointer to an array of access control entries (which had the form of
user or group followed by its permissions and its type) but it would be
useful to have a way of setting that information via the command line.

Switching topics - your idea topic of extending "net" to include the share
RPC calls is a reasonable idea since there is some additional function that
could be picked up that may not be invokeable via RAP (and RPC may be
slightly more secure), but as a higher priority I would like to see "net"
improved to work for a larger set of operations (and most of these are
going to be, by default, invoking RPC) so command line scripting whether it
be to Windows or Samba can be done in one place (and I would like us to
define/document some of the local CIFS-related programming library API for
GUIs to call into the Samba client framework).    It is unfortunate that
the RPC mechanism (RAP vs. DCE/RPC etc.) is now required to be known by the
user of the net command (our idea was to make the explicit choice of RPC
vs. RAP vs. LDAP etc. optional and rarely used).   Users/Admins shouldn't
care about the actual remoting mechanism (although I don't mind them
explicitly overriding the order that the net code invokes this) - that is
what computers are for...   I also had imagined a registration mechanism by
which OEMs could add alternative remoting mechanisms (e.g. SOAP etc.)  and
map the management functions (which would default to RPC or RAP depending
on the operation) to their own server specific needs (I was thinking of PAM
as an example of a framework such as this).

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at us.ibm.com