[Top] [All Lists]

Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs

To: Andreas Gruenbacher <agruen@xxxxxxx>
Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs
From: Ben Martin <monkeyiq@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 11 Nov 2002 21:55:23 +1000
Cc: acl-devel@xxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Mon, 2002-11-11 at 01:26, Andreas Gruenbacher wrote:
> On Sunday 10 November 2002 14:09, Ben Martin wrote:
> > On Sat, 2002-11-09 at 22:11, Ethan Benson wrote:
> > > On Sat, Nov 09, 2002 at 09:52:14PM +1000, Ben Martin wrote:
> > > > $ ll -d video
> > > > lrwxrwx---    1 ben      ben            12 Aug 22 18:59 video ->
> > > > /diskzilla/video/
> > > > $ setfattr --name=user.fred -h --value=foo ./video
> > > > setfattr: ./video: Operation not permitted
> > > >
> > > > Is there a security issue here for setting EA on softlinks that one
> > > > owns? I use EA to store icon name, x, y etc info in the object itself,
> > > > and anything else I add to get around this will be a poor very app
> > > > specific hack. I'm just hopefull that maybe security was maybe
> > > > tightened too far or I have made a slip up?
> > >
> > > i don't believe there is a security problem with allowing EA for the
> > > owner only on symlinks, i think the reason its not allowed is because
> > > that would require special casing the security rules for user.*
> > > namespace.  the user.* namespace is controlled by standard unix file
> > > permissions (which are supposed to be irrelevant on symlinks). it
> > > would be messy to add special casing for where its permissions for
> > > normal files and file owner for symlinks.
> >
> > hmm, I agree it would add yet another complication, but without such a
> > case I think that many userland tools will build functions to do a
> > similar thing in a app dependent way (eg, setting normal EA on a .xxx
> > file for a symlink xxx). I'd love make 100% sure that the
> > if( symlink && owner == current-id )
> > case is hated before I think of other ways around it (which might well
> > be making the personal patch available to allow the above case).
> The access rules for the user.* namespace are already complicated enough; I 
> don't want to further complicate them. We have been anticipating additional 
> namespaces with different access semantics, but nothing has been implemented 
> yet:
> owner.*
>       Allow access to the owner and to users capable of CAP_FOWNER.

OK, so if I defaulted to user.ferris-icon-x and then tried
owner.ferris-icon-x I would have a somewhat valid solution. Also this
would allow the user to copy the symlink and preserve the metadata
fairly easily. 

> trusted.*
>       Allow access to users capable of CAP_SYS_ADMIN.
> > > rather then complicate the code in the kernel its just forbidden to
> > > set EAs on symlinks at all (unless your root probably).
> Yes, user.* EAs are not allowed, but other kinds may be added that can be set 
> on symlinks.

I presume that patches are accepted :) If I am using XFS to store my EA
then from the above I am going to attack some kernel VFS code to get the
owner.* semantics, who do I send patches to?

> > > the designers of the xattr interface want to keep the rules for
> > > various namespaces very clear and consistent, adding special cases
> > > like this violates that order.
> >
> > I am wondering if it will make the system too simple for folks other
> > than myself, who are storing per object metadata in EA and their systems
> > break or display poorly for directories that the user has created
> > symlinks in. Sort of trying to see if there is a community who think
> > that the special case is worth existing or not.
> The symlinks are usually thought of being references to objects only, not 
> first-class objects on their own.
> Which information do you want to attach to the symlink that you can't attach 
> to the object pointed to in the first place?

Basically its for multi desktop management. 
eg. I have ~/.ego/desktopN/ which has a bunch of symlinks for desktop N
and a few special fake files for running raw scheme code. I may wish to
represent /tmp in two views, one with a small icon on the right hand
side of the screen just for convenience and on another desktop I might
want /tmp with a 64x64 icon and be more prominent on the screen at top
left. So as my code stands right now I store
as EA on the object itself, be it a file/dir/symlink. This way the
symlinks can have different icons and locations.

> --Andreas.
In this world there are only two tragedies.  
One is not getting what one wants, 
and the other is getting it.
                -- Oscar Wilde

<Prev in Thread] Current Thread [Next in Thread>