On Monday 11 November 2002 12:55, Ben Martin wrote:
> 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?
I feel somewhat responsible for ext2/ext3, and slightly less so for reiserfs.
For XFS the right contact would be Nathan Scott, or the linux-xfs list. We
should try to make a coordinated move.
> > 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.
I see. The benefit over implementing this via special files seems to be that
the symlink can be used by applications in the usual ways. Still it's seems
kind of ugly to me...