I've been watching these EA/ACL implimentation discussions going on for
a while now, and honestly not completely understanding everything.
However, I know this is obvious to many of you, but...
Thank you very much. Being on these mailing lists, it is always amazing
to me to see the amount of time that goes into these discussions. The
end users may never know about these things, but will quickly become
dependant on them soon after implimentation. I'd just like to extend my
gratitude in the manner in which everyone discusses these things in an
open forum and in the end something will get worked out.
Some times I take for granted the opportunities that the Open Source
community have given me. but when I read a discussion about Extended
Attributes of filesystems, that are so obviously important and yet so
completely missed by most people, I am reminded how great this community
is.
Thanks again, I look forward to the end results from you all.
Chris Tooley
Austin Museum of Art
On Wed, 2001-12-12 at 15:26, Nathan Scott wrote:
> hi,
>
> On Wed, Dec 12, 2001 at 12:39:00PM +0100, Luka Renko wrote:
> > Nate Amsden wrote:
> >
> > > Luka Renko wrote:
> > > > It seems that EA implementation has the following limitations:
> > > >
> > > > 1. Symbolic links
> > > > EA will get stored on inode where symbolic link points
> > > (follow_link)
> > > > and not on symbolic link inode itself (I have used EA utilities and
> > > > also my own C program using ext_attr_path() system call -
> > > both with no
> > > > success). Since symbolic link is inode itself, I see no
> > > reason not to
> > > > support EA on symbolic link itself.
> > >
> > > that sounds normal. afterall a symbolic link is just a
> > > pointer. i can't imagine why someone would want special
> > > permissions on a symlink.
> >
> > But I am not talking about permissions (rwx) or ACLs - I understand your
> > point, that it makes no sense two have permissions on symbolic links.
> > What I am talking about is Extended Attributes - and how I understand EA,
> > they are just property of an inode, and since symbolic link is an inode, I
> > would expect I can set EA for symbolic link inode and not the inode where
> > symbolic link points.
> >
>
> Andreas' syscall interface doesn't allow symlinks to support
> EAs (since he's approaching the problem from an ACL/security
> attribute point of view, this is hardly surprising).
>
> The current interface proposal thats floating around does
> allow this, and XFS has always supported EAs on symlinks.
>
> >
> > OK, but again: I am talking about EA and I don't see a reason this should
> > not work.
> >
> > >
> > > is there some other system you've used that allows what you
> > > specify in #1 and #2 ?
> >
> > I know that on Windows all file entries (files, directories, including W2K
> > reparse points), can have extended attributes). I know that Windows does not
> > have symbolic links and special files like UNIX, but their implementation
> > seems consistent (they have EA and they support it on all file/dir/whatever
> > objects on the filesystem).
> > I will actually look into SGI's XFS and try to find out if they EA
> > implementation has similar limitations. However, since they support DMAPI
> > (API used by HSM applications) which supports attributes for all objects, I
> > would imagine that they support any file type (but I have to check and
> > confirm).
>
> Yes, XFS does support this. Andreas posted to linux-kernel
> a few weeks ago stating his reasons for not supporting EAs on
> device special files in ext2, and we discussed it privately
> once as well - not sure I agree with those reasons, but all
> of the interfaces have always allowed this and it does work
> in XFS.
>
> cheers.
>
> --
> Nathan
> _______________________________________________
> acl-devel mailing list
> acl-devel@xxxxxxxxxxx
> http://acl.bestbits.at/mailman/listinfo/acl-devel
|