Sam,
Aren't we bouncing back and forth on features that we've added?
yeah; I know :) sorry about that..
what do you think we should do? :)
Regarding the patch: Does this conflict with what's in
pvfs2_get_sb? When we create the root inode we specify the sticky
bit there as well.
yes it does conflict.. D'oh I cannot even generate patches properly these days
I missed the changes I had made locally to super.c..
Just remove the S_ISVTX changes like you mentioned.
thanks!
Murali
-sam
On Jun 28, 2007, at 1:57 PM, Murali Vilayannur wrote:
> oops.. wrong file..
> Resending patch..
> Murali
>
> On 6/28/07, Murali Vilayannur <[EMAIL PROTECTED]> wrote:
>> Hey rob,
>> I agree; I forget the history behind why we added all this in the
>> first place :)
>> Do you guys recollect?
>> Anyways, attached patch should fix this cleanly..
>> We have to doc on the FAQ that top-level directories are for
>> root-users only henceforth.
>> We should also recommend that people do a chown 755 on the root
>> directory as well in case they don't wish to reformat.
>> Phil, you should be able to do setfattr and getfattr on root
>> directory
>> with or without the mount time acl option with this patch.
>> thanks,
>> Murali
>>
>> On 6/28/07, Rob Ross <[EMAIL PROTECTED]> wrote:
>> > seems like this is something that admins have had to deal with
>> forever;
>> > we're not asking anyone to do anything unusual... -- rob
>> >
>> > Murali Vilayannur wrote:
>> > > Hi Sam,
>> > > You mean remove it for good from the code, right?
>> > > A chmod -t does not do the trick. We explicitly reset it
>> internally
>> > > sadly :(
>> > > 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
>> > >
>> >
>>
>>
>> <perm.patch>
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
