I seem to have stepped into a stickier problem that I realized :)
I didn't intend for you guys to have to undo a bunch of stuff to get
xattrs on root- it isn't that big of a deal. Its fine if this is just a
FAQ entry.
It does seem like the best of both worlds would be to have the
"automatically sticky root dir" feature be optional (default to yes)
based on the server config, but that sounds like it may be more trouble
than its worth.
-Phil
Sam Lang wrote:
On Jun 28, 2007, at 2:02 PM, Murali Vilayannur wrote:
Sam,
That's only on mount though, right?
On every getattr, sadly :(
Could we remove the sticky bit
while mounted so that extended attributes can be added? The kernel
doesn't check if xattrs already exist on a root dir when the file is
mounted, does it?
hmm. we sorta rely on the sticky bit for 2 things,
- users cannot create files under directories owned by others
- users cannot delete files/directories owned by others.
So we cannot remove it since we got a lot of permission checks for free..
So in many ways we mimic'ed /tmp/
Sure. Those seemed like good things to have (and we already have
them). We're removing those features now?
Anyways, the patch that I sent should take care of these issues.
We shall push the onus onto admins like robr said and it is not an
unusual request anyways.
Seems like we're vacillating. Maybe its too much work to add an option
that enables/disables the sticky bit on the root dir, but if setting
extended attributes is the only win without the sticky bit, and we lose
the ability for users to add directories to the root themselves (like
/tmp as you mention), it seems like the latter is more generally useful.
For the sticky bit thing -- could we set something on the server
maintaining the root dir to specify whether to add the sticky bit
when we mount? The config file could have a sticky bit enable/
disable option.
I think servers should not know about these issues like what we have
today.
sticky bit is an in-memory thing for pvfs2. servers do not know about
it at all.
anyways, I think we should move away from this sticky bit and let
admins deal
with the fallout..
what do you think?
I guess it seems like we (you especially) already spent the time to
think about this, and came up with the sticky bit as the best option.
You implemented it, and its in the code. I think its generally useful
to have -- sure we can make admins do more work -- but we're not adding
functionality here, we're taking it away.
I agree with Phil that it would be nice to set an xattr on the root do
and let it get inherited for the entire fs, but I'm not sure we've spent
much time thinking about that. Certainly we already have a config
option for the distribution -- and all files inherit that dist. Are we
going to get rid of that option? Otherwise, won't it conflict with the
dist_name xattr that we can set on dirs?
-sam
thanks,
Murali
-sam
> I will send out a patch to do this trick *if* folks are willing to
> live with no top-level
> files or dirs...
> Murali
>
> On 6/28/07, Sam Lang <[EMAIL PROTECTED]> wrote:
>>
>> Hi Murali,
>>
>> Can't we just have people remove the sticky bit so they can set
>> xattrs?
>>
>> -sam
>>
>> On Jun 28, 2007, at 12:37 PM, Murali Vilayannur wrote:
>>
>> > Phil,
>> > Umm.. The problem is that we mark the root directory as sticky
>> so that
>> > users can create files/directories at the top level instead of
>> having
>> > admins create directories owned by a user under top level. The
>> kernel
>> > does not allow setxattr on inodes marked sticky..
>> >
>> > if (!strncmp(name, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN)) {
>> > if (!S_ISREG(inode->i_mode) &&
>> > (!S_ISDIR(inode->i_mode) || inode->i_mode &
>> > S_ISVTX)) <--
>> > return -EPERM;
>> > }
>> > Thats why we don't even have a chance to subvirt those checks..
>> > What do you guys suggest? Shall we step back and make the root
>> > directory non-sticky by default? That way admins will need to
>> > explicitly create user directories etc and chown them.
>> > I think a rerun of ltp may also be required if we do this change.
>> > comments?
>> > Murali
>> >
>> > On 6/28/07, Phil Carns <[EMAIL PROTECTED]> wrote:
>> >> This is with 2.6 (both very recent and relatively old
>> version). Many
>> >> thanks for looking at it.
>> >>
>> >> -Phil
>> >>
>> >> Murali Vilayannur wrote:
>> >> > hi Phil,
>> >> > Are you using 2.4. kernel versions? or 2.6?
>> >> > If xattrs dont work, ACLs also won't work.
>> >> > I will dig into this and let you know what I find out..
>> >> > thanks,
>> >> > Murali
>> >> >
>> >> > On 6/28/07, Phil Carns <[EMAIL PROTECTED]> wrote:
>> >> >> I am interested in this because it would be nice to be able
>> to set
>> >> >> tuning options at the root directory level without modifying
>> >> the server
>> >> >> side configuration files. I also wonder if this issue would
>> cause
>> >> >> problems for ACLs on the root directory.
>> >> >>
>> >> >> -Phil
>> >> >>
>> >> >> Murali Vilayannur wrote:
>> >> >> > Hey Phil,
>> >> >> > Sorry I forgot to get back to you on this..
>> >> >> > No I don't think this would work.
>> >> >> > It is a kernel module issue that I hadnt tracked down fully..
>> >> >> > Do you need this feature?
>> >> >> > thanks,
>> >> >> > Murali
>> >> >> >
>> >> >> > On 6/27/07, Phil Carns <[EMAIL PROTECTED]> wrote:
>> >> >> >> Just pinging on this one again- has any one else bumped into
>> >> this
>> >> >> >> problem?
>> >> >> >>
>> >> >> >> -Phil
>> >> >> >>
>> >> >> >> Phil Carns wrote:
>> >> >> >> > It looks like pvfs2 does not allow you to set xattrs on
>> >> the root
>> >> >> >> > directory. Is this expected?
>> >> >> >> >
>> >> >> >> > # checking the mount options:
>> >> >> >> >
>> >> >> >> > > mount -t pvfs2
>> >> >> >> > tcp://localhost:3334/pvfs2-fs on /mnt/pvfs2 type pvfs2
>> >> >> (rw,user_xattr)
>> >> >> >> >
>> >> >> >> > # confirming that xattrs can be set on a normal directory:
>> >> >> >> >
>> >> >> >> > > setfattr -n user.pvfs2.num_dfiles -v "1" /mnt/pvfs2/
>> dir1
>> >> >> >> > > getfattr -n user.pvfs2.num_dfiles /mnt/pvfs2/dir1
>> >> >> >> > getfattr: Removing leading '/' from absolute path names
>> >> >> >> > # file: mnt/pvfs2/dir1
>> >> >> >> > user.pvfs2.num_dfiles="1"
>> >> >> >> >
>> >> >> >> > # trying to set xattrs on the root directory:
>> >> >> >> >
>> >> >> >> > > setfattr -n user.pvfs2.num_dfiles -v "1" /mnt/pvfs2
>> >> >> >> > setfattr: /mnt/pvfs2: Operation not permitted
>> >> >> >> > > getfattr -n user.pvfs2.num_dfiles /mnt/pvfs2
>> >> >> >> > /mnt/pvfs2: user.pvfs2.num_dfiles: No such attribute
>> >> >> >> >
>> >> >> >> > All of the above is run as root. I don't think it is
>> >> anything
>> >> >> special
>> >> >> >> > about the num_dfiles attribute either; it looks like I
>> >> can't set any
>> >> >> >> > xattrs on the root directory. It always responds with
>> >> "Operation
>> >> >> not
>> >> >> >> > permitted".
>> >> >> >> >
>> >> >> >> > -Phil
>> >> >> >> >
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Pvfs2-developers mailing list
>> >> >> >> [email protected]
>> >> >> >> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-
>> >> developers
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> > _______________________________________________
>> > Pvfs2-developers mailing list
>> > [email protected]
>> > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-
>> developers
>> >
>>
>>
>
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
