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
> 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
> 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.
In this world there are only two tragedies.
One is not getting what one wants,
and the other is getting it.
-- Oscar Wilde