On Wed, 2002-09-18 at 06:17, Nils Philippsen wrote: > > Ian McKellar said: > > > it will also need to expose this GNOME_VFS_PERM_ACCESS_* API so that > > apps who don't care about the details can find out what they want. > > That's what I wanted to say: I would like to at least deprecate (if not > forbid) using the permissions member directly in favour of using > setter/getter functions for two reasons: > [snip: redundancy, legacy helper] We have the GnomeVFSFileInfoFields enum that lets a module and/or GnomeVFS explain to higher levels which parts of the FileInfo struct are valid, so on filesystems that use ACLs rather than unix-style permissions the unix permissions bit will not be set but the ACLs bit will. Almost all apps (the exceptions being things like Nautilus that are designed for inspecting the fileystem closely) will just look at the PERM_ACCESS_* field and so won't care how permissions are done on the filesystem. > > > I'll be eager to look at proposed APIs that people have for ACL support. > > I have little knowledge of (or indeed personal interest in) ACLs. I am > > open to people who do care though. It sounds like the sort of thing that > > will take more thinking and discussion than we'll have time for before > > 2.2. But now is a good time to start talking about it. > > OK, let me wrap up what I've got in mind currently: > > We need objects for: > > - GnomeVFSUser, GnomeVFSGroup: users and groups (very lightweight, I don't > want to implement every aspect, rather just identify them) Will GnomeVFSUser always map to local UNIX users? (I imagine not, but correct me if I'm wrong) Will the current UNIX user ever have more than one GnomeVFSUser associated with them? What kind of information will we be able to get out of a GnomeVFSUser structure? Login? Full Name? GECOS metadata? Quota? > - GnomeVFSUserNamespace: "namespaces" in which users/groups are valid, > this will in most cases be just what I'd call the URI root, e.g. "file://" > for "file:/usr/share/blah", "http://machine"; for > "http://user!password machine/path/to/file" and the like Would it be useful to extend this to the concept of "volumes" that we have very primitive support for (gnome_vfs_get_volume_free_space, volume monitors in Nautilus)? > - GnomeVFSPermissions: permissions objects which (opaquely) describe who > can do what with a file > > The relations are as follows: > > - users, groups are tied to a namespace > - permissions are tied to GnomeVFSFileInfo objects > > The following functions should be there (mostly self explanatory): > > - Functions to get lists of users/groups, needed e.g. for modifying > permissions in nautilus: > > GList *gnome_vfs_namespace_get_users (GnomeVFSNamespace* ns) > GList *gnome_vfs_namespace_get_groups (GnomeVFSNamespace* ns) > possibly wrapped up into "convenience" functions: > GList *gnome_vfs_file_get_users (GnomeVFSURI* uri) > GList *gnome_vfs_file_get_groups (GnomeVFSURI* uri) do we need/want get_current_user and get_user_groups too? > > - Function to get the namespace for a file: > > GnomeVFSUserNamespace *gnome_vfs_file_get_namespace (GnomeVFSURI *uri) I guess we'll want a funtion to get the root URI of a namespace? > > - Function for permissions/access: > > GnomeVFSPermissions* gnome_vfs_file_get_permissions(GnomeVFSURI *uri) Should this take a FileInfo instead? > gint gnome_vfs_file_set_permissions (GnomeVFSURI *uri, > GnomeVFSPermissions *perms) You wouldneed to supply a permissions object thats valid for the given URI. Perhaps GnomeVFSPermissions could keep a reference to the URI its was gotten for? In fact, if GnomeVFSPermissions is part of GnomeVFSFileInfo this could become part of the functionality of gnome_vfs_set_file_info. > gboolean gnome_vfs_file_access_user (GnomeVFSURI *uri, > GnomeVFSUser *user, > GnomeVFSAccessType access) > more conveniently for the current process: > gboolean gnome_vfs_file_access (GnomeVFSURI *uri, > GnomeVFSAccessType access); That all sounds pretty interesting, especially if we can integrate it closely with the current FileInfo stuff. I'm interested in what sort of interface these User, Group, Permissions and Namespace objects would have. I don't really know much about ACLs though, is there a good explanation online of the concepts and the various models you're hoping to support? Theres my twenty questions :) Ian
Attachment:
signature.asc
Description: This is a digitally signed message part