GNOME Bugzilla – Bug 62835
Add ACL support
Last modified: 2006-07-14 15:32:31 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.
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:').
Created attachment 53658 [details] [review] Patch implementing ACL support This patch implements ACL support: base and file backend..
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
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.
Yeah, given that GnomeVFSFileACL is simply a container for POSIX ACLs (an opaque structure), how would it deal with the infinitely richer NT ACLs?
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.
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?
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?
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.
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).
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 :)
Created attachment 54774 [details] Discussion about last patch. Gicmo and I had a discussion about this on irc. Attaching the log.
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);
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.
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.
ACL support has landed in HEAD some time ago. Closing.