xfs
[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 
yet:

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

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.

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

--Andreas.



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