xfs
[Top] [All Lists]

Re: User EA on symlinks, 2.4.19-xfs

To: linux-xfs@xxxxxxxxxxx
Subject: Re: User EA on symlinks, 2.4.19-xfs
From: Ethan Benson <erbenson@xxxxxxxxxx>
Date: Sat, 9 Nov 2002 03:11:56 -0900
In-reply-to: <200211091152.gA9BqEk25512@monkeyiq.dnsalias.org>
Mail-copies-to: nobody
Mail-followup-to: linux-xfs@xxxxxxxxxxx
References: <200211091152.gA9BqEk25512@monkeyiq.dnsalias.org>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
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.

rather then complicate the code in the kernel its just forbidden to
set EAs on symlinks at all (unless your root probably). 

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.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpR1jNkdJJRC.pgp
Description: PGP signature

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