ACL / SD support

[John E. Malmberg]

I mis-understood at first what Michael Stockman wrote when he wrote that he
was "Starting with the ACL part".

I had jumped to the incorrect conclusion that by the ACL part, he was
implementing a method of storing security descriptors that the SMBD would
honor and display and allow modifications from Windows clients.  This is why
I was curious about the storage of these.  Since I was on the wrong track,
that does not matter.


Michael Stockman <pgmtekn-micke at algonet.se> wrote:
> John Malmberg wrote:
> > I would recommend representing the HIDDEN, READONLY, and SYSTEM
> > attributes as one of these special meaning values.
> >
> > I noted in earlier post (SURS thread) that mapping the READONLY
> > attribute to the UID based protection has problems if you allow a
> > user to toggle it to allow writing to the file.  Representing this as a
> > special identity solves this problem, while adding another, in this
> > case, that the host system will not neccessarily honor it.
>
> I don't quite follow you. I should perhaps point out that samba cannot
> alter your unix system and support more than it can.
> Second, are attributes stored in the ACL/SD? I don't think I've seen
> it on NT and I doubt on unix.

An ACL list is just one way to store extended file attributes.  Primarily
they are used to store security information, but they are not limited to
that function.

I will admit that most of the user interfaces are limited to displaying and
manipulating this information.  The programming API however allows access to
the other functionality.

If you make the ACE look like a security entry even when it is not used for
that, then the existing file security manipulation commands can be used to
modify it instead of needed a separate program.  The trade off is that you
use multiple ACEs that are easy to read instead of an ACE that the standard
utilities report as application specific in uniterpreted hex codes.


The method that SAMBA uses to map the DOS attributes into a protection mask
introduces a small security hole if it is followed in OpenVMS.

In OpenVMS, the eXecute permission, allows that class of users to run a
program or command file (shell script), even if they do not have read access
to it.  It also allows access to files in a directory if you know the
filename when you do not have read access to the directory.


For the HIDDEN and SYSTEM attributes, on a host platform that supports ACLs,
this is the obvious place to store them and not introduce security
anomilies.

The READONLY attribute is still problematic if you allow the user to clear
it.  For a protection mask, you have no information on what it is safe to
write enable.

If you store as an ACE that is part of an ACL and the host operating system
does not already have a READONLY equivalent builtin right, then you have to
decide if you want to add the READONLY right to all the accounts.  If you do
not, then those accounts will not be restricted by the READONLY
characteristics.


> > If it is desired to have the state of the following attributes
> > reported and or updated from a Windows system, then
> > they can also be represented as special meaning values:
> >
> > sticky, setuid, setgid, manditory locking, append only, etc...
>
> If I'm correct, you want samba to check for these file attributes and
> have samba create ACL entries with special users in case they are
> there? If so, you don't need special values, you need ordinary users
> that are interpreted specially in the read and write SD functions,
> because NT must know the user. Your suggestion counts as a hack.

Yes, it is a hack.  One that could be useful to some, but heresy to others.

NT does not need to know the user, it is simply a name associated with a
unique number with properties that SMBD returns in a way that can be
interpreted the lanman client.

However as those attributes listed above are not present on an OpenVMS
filesystem, I do not have much energy on this issue.


I also notice that there is a LINUX file system that supports compression.
It could be a hack to report and allow setting of the compression when an NT
system is accessing it, as that is one of the attributes that NT supports.

Of course there is always the trade off between feature creep, and deadlines
for a stable release.

> > A default protection and inheritance type is needed.  This is
> > implemented in NT 4.0 SP4.  The commands to display and
> > manipulate this are in W2K or a patch kit for NT 4.0.

> I don't quite see what you are asking for.

> > How does the Security Descriptor information get
> > propagated to a new version of a file when using
> > a native UNIX utility such as VI or EMACS?
>
> I don't see what you mean.
>
Now that I understand what you are doing, I agree that it is not relevant.

It would only be relevant if you were mapping a host ACL system behavior to
NT ACL behavior, or adding an ACL system to a UNIX or LINUX filesystem.

-John
wb8tyw at qsl.net