[Top] [All Lists]

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

To: Ben Martin <monkeyiq@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs
From: Andreas Gruenbacher <agruen@xxxxxxx>
Date: Sun, 10 Nov 2002 16:26:45 +0100
Cc: acl-devel@xxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
In-reply-to: <200211101309.gAAD9X525574@xxxxxxxxxxxxxxxxxxxxx>
Organization: SuSE Linux AG
References: <200211101309.gAAD9X525574@xxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: KMail/1.4.3
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 

        Allow access to the owner and to users capable of CAP_FOWNER.

        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.

> > 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?


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