File Permission Suggestion

[Esh, Andrew]

I have been working with Access Control Lists (ACL), and I have a suggestion
which may improve Samba's file permission handling. For those of you who are
not aware of what ACLs are, here is a short description:

Access Control Lists are per-file or folder information that records the
settings which allow access to the file. The list entries contain a
reference to a user or group, and the associated security settings which
that user or group is subjected to when they access the file or folder. In
Windows, you control these settings by right-clicking the file or folder,
and selecting "Properties". In that dialog, on the Security tab, there is a
"Permissions" button which opens the file permissions dialog. Each line
shown in the list in that dialog represents one ACL setting. The ACLs which
Samba supports don't quite work the same way as Windows ones, because under
the covers, Samba has to make use of the Unix permission settings. On Linux,
those settings include the familiar User, Group, and Other settings, each
being associated with Read, Write, and Execute permission. Linux also has
Posix ACLs, which allow the same Read, Write, and Execute permissions to be
given to added users and groups.

Here's the issue: When a Windows client is connected to Samba with ACL
support, and "nt acl support = yes", the Security tab is shown to the
client, and the Permission dialog is operative. The problem is, some of the
normal Windows look and feel is different: The Unix User, Group, and Other
lines are represented as User, Group, and Everyone ACL settings. This was
been useful before Linux had Posix ACL support, since the only way to
control access to a file under Samba was through the Unix permissions. Now
that we have ACLs, we need another option.

My suggestion is to change Samba so the three User, Group, and Other lines
are not shown in the Permission dialog. The file ownership is maintained,
and is displayed in the top of the dialog, as it is in Windows. If Posix ACL
settings are present for the file, lines of ACL permission are displayed in
the Permissions dialog. The only use for the User permissions which are
applied directly to the file (even without Posix ACLs), is to maintain the
identity of the owner, and allow the owner to add ACL permissions when there
are none. One additional feature: When a new file is created, an ACL must be
added to it to represent the default creation permissions which are assigned
when Windows creates a file. Note that this line can later be removed using
the Permissions dialog, because it would be represented by an ACL.

To see the functionality I am asking for, open a networked drive to an NT
server. Create a temporary file, and open the Permissions dialog to it. Note
that there is only one default line of permissions. Remove that line, and
press OK. Re-open the dialog. You will note that the owner is still
correctly listed, and there are no permission lines at all. Note that if you
compare this experiment to one done with Samba, the three default lines of
permission cannot be removed. The dialog acts as though it allows them to be
removed, but they are back the next time the dialog is opened. This confuses
Windows users. Note also during this experiment that when the last line of
permission is removed, a small dialog is shown warning that only the owner
will be able to change permission on the file.

What I am imagining when I consider that empty Permissions dialog, is the
User, Group and Other permissions being set to Read, Write, and Execute for
none. Samba would be changed to support file permission testing only based
on the ACLs, not on the Unix file permissions. The only use of the Unix file
permissions would be to allow changes to the ACL list if the person is the
owner of the file. Samba would have to be superuser while working with a
file which has no ACL permission set on it, since the User has no Write
permission through Unix. Samba would also be changed to only return the ACL
permission listings when Windows asks for the list. It will no longer return
the User, Group, and Other permissions, translated into ACL-like permission
entries.

I realize that this change has problems with files which are also available
to Unix users, possibly shared via NFS. ACL controls set by a Windows user
would still be effective, but any permissions set through Unix would open
the file for use through Unix only. The Samba client would not get those
permissions until a matching ACL is also added to the file.

This suggested change does not address all the extra "Add", "Delete",
"Change Ownership", and other permission bits which Windows expects to be
able to control. That will have to come later. In fact, the system which
stores the Posix ACL settings, known as Extended Attributes, can be used to
attach any sort of data to a file. Extended attributes could be created
which represent all the Windows permission bits. Then if Samba is extended
to store, retrieve, test, and control those attributes, they could be
supported faithfully in the Windows permissions dialog.

What do you think?

---
Andrew C. Esh                mail:Andrew.Esh at tricord.com
Tricord Systems, Inc.
2905 Northwest Blvd., Suite 20        763-557-9005 (main)
Plymouth, MN 55441-2644 USA      763-551-6418 (direct)
http://www.tricord.com - Tricord Home Page


-------------- next part --------------
HTML attachment scrubbed and removed