After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 62835 - Add ACL support
Add ACL support
Status: RESOLVED FIXED
Product: gnome-vfs
Classification: Deprecated
Component: File operations
0.1
Other All
: Normal enhancement
: later
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
Depends on:
Blocks:
 
 
Reported: 2001-10-23 01:38 UTC by Maciej Stachowiak
Modified: 2006-07-14 15:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch implementing ACL support (25.38 KB, patch)
2005-10-19 15:23 UTC, Alvaro Lopez Ortega
none Details | Review
Patch implementing ACL support (33.45 KB, patch)
2005-11-11 10:54 UTC, Alvaro Lopez Ortega
none Details | Review
Discussion about last patch. (9.76 KB, text/plain)
2005-11-15 10:04 UTC, Alexander Larsson
  Details

Description Maciej Stachowiak 2001-10-23 01:38:10 UTC
It would be good if gnome-vfs allowed programs to acess and manage ACLs.
Some of the kinds of ACLs out there include:

For `file:'

* AFS ACLs
* coda ACLs
* Intermezzo ACLs
* XFS/POSIX ACLs

For `http:'

* WebDAV ACLs

We should desgin a good abstraction to handle all of these, so
Nautilus and other applications can reflect and allow management of
ACLs properly.
Comment 1 Maciej Stachowiak 2001-10-23 01:40:14 UTC
Oh yeah, SMB also has ACLs (may be visible through `smb:' module or
through `file:' if the filesystem is mounting), and so does NTFS
(likely to be visible through `file:').
Comment 2 Alvaro Lopez Ortega 2005-10-19 15:23:18 UTC
Created attachment 53658 [details] [review]
Patch implementing ACL support

This patch implements ACL support: base and file backend..
Comment 3 Ilya Konstantinov 2005-10-19 16:48:52 UTC
What's the point of this code?

+#if 0
+	{
+		int which_entry;
+
+		ret = acl_check (acl->acl_default_info, &which_entry);
+		if (ret < 0) {
+			g_print ("Check: ERROR\n");
+		} else if (ret > 0) {
+			char * txt = acl_to_any_text (acl->acl_default_info, NULL, ',', 0);
+			g_print ("Check: MALFORMED: %s: \"%s\" entry %d\n", acl_error(ret), txt,
which_entry+1);
+			g_free (txt);
+		}
+	}
+#endif
Comment 4 Björn Torkelsson 2005-10-19 17:19:10 UTC
At least AFS have some more types than the standard POSIX. See 

http://www.openafs.org/pages/doc/UserGuide/auusg007.htm#HDRWQ46

for a description of the AFS ACL permissions.
Comment 5 Ilya Konstantinov 2005-10-19 17:42:52 UTC
Yeah, given that GnomeVFSFileACL is simply a container for POSIX ACLs (an opaque
structure), how would it deal with the infinitely richer NT ACLs?
Comment 6 Alexander Larsson 2005-10-20 07:32:50 UTC
This doesn't look like what we want. It just turns posix acls into a thin
wrapper object. For instance, there is no way to use the GnomeVFSFileACL object
on webdav.

What we really need is for someone to look at the various ACL systems out there
(unix, webdav, NT, etc) and figure out a nice abstraction that works for all of
them (to the extent that is possible). This abstraction would be in the form of
objects in libgnomevfs that represents the ACL, but are backed by
backend-specific code in the module.
Comment 7 Alvaro Lopez Ortega 2005-10-20 15:32:57 UTC
Just to clarify it, Is this kind of "API" want we are expecting from GNOME-VFS?
These are only some of the constants we could need to support POSIX, Windows,
AFS and WebDAV.

Permissions
===========

/* POSIX
 */
GNOME_VFS_ACL_PERMISSION_READ,
GNOME_VFS_ACL_PERMISSION_WRITE,
GNOME_VFS_ACL_PERMISSION_EXECUTE,

/* DFS
 */
GNOME_VFS_ACL_PERMISSION_CONTROL, 
GNOME_VFS_ACL_PERMISSION_INSERT,
GNOME_VFS_ACL_PERMISSION_DELETE,

/* NT
 */
GNOME_VFS_ACL_PERMISSION_OWNERSHIP,

/* AFS
 */
GNOME_VFS_ACL_PERMISSION_LOOKUP
GNOME_VFS_ACL_PERMISSION_LOCK,
GNOME_VFS_ACL_PERMISSION_A
GNOME_VFS_ACL_PERMISSION_B
GNOME_VFS_ACL_PERMISSION_C
GNOME_VFS_ACL_PERMISSION_D
GNOME_VFS_ACL_PERMISSION_E
GNOME_VFS_ACL_PERMISSION_F
GNOME_VFS_ACL_PERMISSION_G
GNOME_VFS_ACL_PERMISSION_H

/* WebDAV
 */
GNOME_VFS_ACL_PERMISSION_UNLOCK,
GNOME_VFS_ACL_PERMISSION_READ_ACL,
GNOME_VFS_ACL_PERMISSION_READ_CURRENT_USER_PRIVILEGE_SET,
GNOME_VFS_ACL_PERMISSION_WRITE_ACL,
GNOME_VFS_ACL_PERMISSION_BIND,
GNOME_VFS_ACL_PERMISSION_UNBIND


Tags
====

/* POSIX
 */
GNOME_VFS_ACL_TAG_UNDEFINED,
GNOME_VFS_ACL_TAG_USER,
GNOME_VFS_ACL_TAG_GROUP,
GNOME_VFS_ACL_TAG_MASK,
GNOME_VFS_ACL_TAG_OTHER,
GNOME_VFS_ACL_TAG_DEFAULT_USER,
GNOME_VFS_ACL_TAG_DEFAULT_GROUP,
GNOME_VFS_ACL_TAG_DEFAULT_MASK,
GNOME_VFS_ACL_TAG_DEFAULT_OTHER,

/* DFS
 */
GNOME_VFS_ACL_TAG_ANY,
GNOME_VFS_ACL_TAG_UNAUTHENTICATED,
GNOME_VFS_ACL_TAG_FOREIGN_OTHER,
GNOME_VFS_ACL_TAG_FOREIGN_USER,
GNOME_VFS_ACL_TAG_FOREIGN_GROUP


Types
=====
GNOME_VFS_ACL_TYPE_POSSITIVE,
GNOME_VFS_ACL_TYPE_NEGATIVE


Maybe we should take a subset for the most used file systems, support its ACLs
scheme, and try not to overengineer the interface. I suppouse POSIX and Windows
are the two most used systems, so it may be enough for the 95% of the cases.  If
some application want to use an exotic WebDAV feature, it can do it directly..

Comments?
Comment 8 Ilya Konstantinov 2005-10-20 16:07:57 UTC
Windows NT also happens to be the more complex one. Do we only aim to support
DACLs (Access Control) or also SACLs (audit) within this API? Even if we only
support DACLs, NT also adds the concept of Deny rules (ACEs, they call them), so
we should mind them too. Also, NT has SIDs instead of UIDs and over SMB we can
also specify names directly (saving a network lookup), meaning our abstraction
is probably best off naming the users/groups by keeping a literal string (UTF-8
char*).

It looks like libsmbclient accepts the NT security descriptor in the following
format:
REVISION:<revision number>
OWNER:<sid or name>
GROUP:<sid or name>
ACL:<sid or name>:<type>/<flags>/<mask>

The fields of the ACL probably correspond to what's described here:
http://msdn.microsoft.com/library/en-us/secauthz/security/ace_strings.asp
(ACE Strings)

Once we can accomodate POSIX and NT ACLs in a single API, it'll probably be
diverse enough so any additional kinds of permissions would be a piece of cake.

If we try to learn fron NT's design, which unlike POSIX tries to make its ACEs
universally-useful (inviting ISVs to use them for their own purposes), we find
that in the ACE's ACCESS_MASK[1], they define the access permissions with a
32-bit integer, leaving the top 16 bits application-specific. They don't make
any attempt to avoid two different applications from understanding the
application-specific bits differently. Do we wish to go by the same path:
standardize on the basic permissions and leave the rest to be negotiated (over
the application-specific bits) between - say - a WebDAV Properties Page Plugin
and the WebDAV GnomeVFS Plugin?
Comment 9 Alexander Larsson 2005-10-24 08:06:12 UTC
I don't personally know much about ACLs, so I'm not the best person to ask about
a specific API. However, I'll try to explain what we want in more general terms.

* The API should be generic enough that you only need one API that works on
multiple backends with the same client code
* The core of access control with ACLs (read, write, execute file/dir) should be
explicitly supported by the API in a common, easy to use way
* The concepts behind all common ACL systems should be supported (e.g. deny
rules from NT). And you need some way to figure out what concepts a backend
supports.
* For more special features of a ACL system, we might want to support them with
a "looser" API, using e.g. strings defined by the backend specifying the various
possible things you can control access to. This way you avoid having to add
stuff to the header files to support new such things.  However, this isn't as
important as the core file control, as that is what it will be mainly used for,
and creating a nice API for such generic stuff is quite hard.

Unfortunately the gnome-vfs current system for tracking access control is pretty
inadequate, in that it only uses local uids, which isn't very nice for e.g. ftp
or webdav. A new system should avoid the weaknesses of this system. Fortunately
we now have the GNOME_VFS_FILE_INFO_FIELDS_ACCESS stuff, which (when use by
nautilus) will allow us to do access checking sanely.
Comment 10 Alvaro Lopez Ortega 2005-11-11 10:54:27 UTC
Created attachment 54627 [details] [review]
Patch implementing ACL support

This patch replaces the previous one. This one uses a much more generic API
based on string parsing and ACL backends.  It should be suitable for
implementing Windows ACLs as well (the patch includes the base + the POSIX
backend).
Comment 11 Ilya Konstantinov 2005-11-11 15:34:46 UTC
Having looked at it only superficially, it looks very cool and I think we should
start by checking it in. If any API improvements are to come, there's enough
time for that -- the API won't be frozen. The main thing is to finally get ACLs
rolling on Unix...

BTW, there's some string-parsing going on in this one, so let's be extra-careful
about safety there :)
Comment 12 Alexander Larsson 2005-11-15 10:04:39 UTC
Created attachment 54774 [details]
Discussion about last patch.

Gicmo and I had a discussion about this on irc. Attaching the log.
Comment 13 Alexander Larsson 2005-11-16 11:14:14 UTC
Some more API ideas:

<alex> I had an idea about the acl kinds and tags
<alex> We could make them like atoms, that you have to register. That way we
save space and strcmps. We can also pre-allocate the common ones so its easy to use.
<alex> module init would do acl_register_kind("blah")
<alex> apps would use
<alex> static int blah_kind = acl_lookup_kind ("blah")
<alex> and we'd predefine things like ACL_KIND_USER so you'd never have to
lookup them
<alex> then it might be easier to use arrays of tags
<alex> zero terminated
<alex> int tags[] = {ACL_READ, ACL_WRITE, 0};
<alex> acl_add (acl, ACL_USER, "1234", tags);
Comment 14 Mårten Svantesson 2005-11-21 16:43:24 UTC
I am a bit ambivalent to this work. ACL support in Nautilus is needed,
the question is how to get it. A problem is that an API rich enough to
make it possible to implement a general user interface for ACLs is
difficult to specify and implement (both in back end and in front
end). Since the only client probably will be in Nautilus I don't know if
this is worthwhile.

Using the latest patch it is not possible to write a generic front
end. The information exposed through the interface simply isn't enough
to construct a good user interface. Instead one would have to resort
to implement different front end for different ACL schemes.

For ACLs of file systems accessed through file URLs I can not see any
need in the implementation for dividing front end and back end. For
other file systems (i.e. WebDAV et al.) the back end might have
session state not known to a front end.

I propose that we solve the problem on a scheme by scheme basis.

Let's see how it is solved in Linux. Here ACLs are sent to the kernel
through the generic extended attributes interface. Now POSIX ACLs are
implemented, but you can easily imagine other ACL schemes implemented
the same way.

A Posix ACL editor are already implemented as a Nautilus extension
(http://rofi.pinchito.com/eiciel/). Based on this I have started
implementing an AFS ACL editor
(http://people.kth.se/~msv/kvibille-0.1.tar.bz2). Eiciel should
probably be a standard extension distributed with Nautilus. (The
audience for Kvibille might be to small to justify that.)

What are needed are conventions for how these extensions should play
nice with each other and the built in ugo editor of Nautilus. Also a
mechanism for sending opaque data to and from a back end is needed for
WebDAV et al. The API in the patch could be used for that, but I don't
see the point in using a specialized API for something that can not be
used as a common API anyway. It only creates unnecessary troubles for
implementors if they realize that the API doesn't accommodate their
needs.

If we use the Linux way of doing it we also (as far as I can see)
trudge into the age old "metadata in gnome-vfs" territory (bug
#62819, bug #40389 and probably more).

Of course the points above would be moot if GUIs for ACLs are required
outside of Nautilus.
Comment 15 Christian Kellner 2005-11-26 14:33:15 UTC
Initial support for acls has landed on the acl branch of gnome-vfs. I would love
if ppl have a look at it. Alo promised to do the POSIX integration and I will
have a look at the webdav case. Comments are very welcome.
Comment 16 Christian Neumair 2006-07-14 15:32:31 UTC
ACL support has landed in HEAD some time ago. Closing.