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

[Alex Graveley <alex ximian com>]

Hi,

On Thu, 2002-08-29 at 07:50, Michael Meeks wrote:
> Hi Alex,
> 
> On Wed, 2002-08-28 at 23:58, Alex Graveley wrote:
> > So on thinking about this more, I really think a permissions system
> > should be abstracted from gnome-vfs entirely.  We should have a generic
> > rights/priveledges framework ala Windows.  
> 
> 	I i magine with Windows it's not a user-level rights/priviledges
> framework - but something that goes to the core of the system.

Well, both really.

> > Having a separate library could enable its use outside of gnome-vfs, and
> > for things which don't closely fit with the file construct.  Things like
> > bonobo/corba call-level security,
> 
> 	Interesting - but how do you propose achieving this.

By implementing the relevant CORBA Security bits, I guess.

> >  gobject instantiation
> 
> 	Some gobject are not instantiable ? that's a joke - user-level
> in-process 'advisory' 'security' is no security.

Yayaya, it was just to establish the point that a decently abstract ACL
API could possibly be useful.

> > gconf settings, user impersonation, system configuration,
> 
> 	How do you possibly plan to stop users impersonating others - it's just
> not feasible; as long as the 'user' string is included in some
> wire-level protocol - it's not going to work; this is a really hard
> problem to solve.

Interesting, considering redcarpet, up2date, and the setup tools all do
it.  I think it would be very nice to have a clean interface for doing
this (crap)... a small suid proggie that receives a serialized security
token on an fd, verifies a hash contained therein against the system
password, and then executes the specified program as the verified user.

> > windows SMB/NTLM integration, keyring management, etc.
> 
> 	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.

> 	In summary - now I think about it I'm completely confused about the
> usefulness / role of ACLs in gnome-vfs.
>
> 	What are people hoping to achieve with new API here ? what is the
> purpose of this code, and the basic requirements ?

ACL support is needed in gnome-vfs, certainly.  Linux will eventually
have it, and there are a lot of powerful things you simply cannot do
with standard unix file permissions.  Not to mention that several major
unix distributions only support 8 groups per user.

The other point to having it in gnome-vfs is that the support for this
is not-standard, and differing implementations exist.  An abstraction is
needed.

(Please keep this discussion going, I think it is *important*)

-Alex

-- 
 on the canvass of life, incompetence is my paintbrush.