Re: Advanced Permissions


Am Sonntag, den 21.08.2005, 00:46 +0200 schrieb Christian Neumair:
> Am Sonntag, den 21.08.2005, 00:41 +0200 schrieb Christian Neumair:
> > Am Samstag, den 20.08.2005, 12:36 -0400 schrieb Chris Spencer:
> > > I (...) was surprised when (Nautilus) began  (...) locking me out of\
> > > certain folders (...). I attempted to access the directory with Konqueror,
> > > and quickly discovered  the folder was using "Advanced Permissions".
> > 
> > ACLs are not yet implemented. It's a shame! We should definitly have it
> > for 2.14. Things to consider:
> > 
> > * we need gnome-vfs API in the background before adding an UI
> >    CCing Christian Kellner.
> *really* CCing Christian Kellner.
> >    Christian: Is there any plan of action for adding this to GnomeVFS
> > 2.14?
> > 
> > * how should the UI look?
> >    a) add an additional tab to the property pages
> >    b) replace the permission table

The traditional unix permissions are only a special case of the acl
permissions, so logically they really are rows in the acl table. 

> > 
> > My idea would be to keep around an ACL listview that contains User,
> > Read, Write and Execute columns. Each row represents an ACL entry. Rows
> > can of course only be modified based if your access rights are
> > sufficient.
> > 
> > If we implement b), the list view would have three rows by default:
> > Owner, Owner's Group, Other, which can of course not be removed.

(nitpicking side note: it isnt "Owner's Group", but actually a totally
unrelated group that just happens to also need access to the file)

Unfortunately adding acls isnt quite as easy as it sounds, since
depending on the actual filesystem, what the acls can do (i.e. at least
the "columns") differs a bit (posix acls and nt acls come to mind
immediately, but I'm sure there are more)

Also, some permission systems support inheritation, that is, permissions
set on a parent folder will also apply to the contents, except when they
are *cough* "removed" there again.

This inheritation will make the "executable" bit ambiguous, since its
not clear then if
a) files in there can be executed or just
b) subfolders in there can be entered 
by the named user x. 

This can get messy. (If I were a kernel developer, I'd just split
"execute program" and "enter directory" into _two_ permissions. sigh.)

So the acl stuff is really something that needs to be designed through
first. (best by a systems admin who actually uses acls every day or


-- key id A334AEA6

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]