Re: Ideas for "extended permissions" (ACLs) in GnomeVFS

On Thu, 2002-08-29 at 19:56, Alex Graveley wrote:
> On Thu, 2002-08-29 at 07:50, Michael Meeks wrote:
> > 	Now - doing central authentication and key management is indeed most
> > useful; Hallski was going to do a GEP on this, it'd be great to badger
> > him about that so we can get some decent requirements on 'paper'.
> The point is that this should all be integrated... spawning other-user
> processes, modifying file permissions or ACLs, modifying keyrings, and
> getting handles to existing authentication tokens for websites.  There
> is not one-api-to-rule-them-all per se, but having virtualized 
> 	GnomeUser
> 	GnomeUserGroup
> 	GnomePermission
> 	GnomeAuthToken
> 	GnomeAuthCache
> objects that can be used for across all of the above makes a lot of
> sense I think.

I agree with you that it'd be very useful to have a generalized
permissions-for-everything API, but I have aimed that high in the past
and failed (mostly due to lack of time). For a first shot I'd like to
stay with permissions for files; I think this is an overseeable amount
of work. For this, I'd also like to stay under the gnome-vfs "umbrella".
If we ever have a more generalized (== "not only for files") API, this
can easily be extracted from gnome-vfs and be put into its own library,
libgnome, glib or whatever else.

Michael, just for illustratioon: the purpose of this code is for me to
be able to manipulate ACLs within Nautilus (when they arrive of course).
Hacking Nautilus directly would count as "aiming too low" for me ;-).

Anyway, I'll be on vacation from tomorrow for the next two weeks and I
very probably won't have net access. I'm already eager to read what you
will have discussed in the meantime, maybe I'll get one or two ideas by
myself as well.

Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg //
   nils wombat dialup fht-esslingen de / nils redhat de / nils lisas de
   PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
       Ever noticed that common sense isn't really all that common?

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]