Re: nfs insecure_locks / Tru64 behaviour

[Ron Peterson]

On Thu, Dec 22, 2005 at 06:21:53PM -0500, Trond Myklebust wrote:
> On Thu, 2005-12-22 at 08:36 -0500, Ron Peterson wrote:
> > If I mount a linux export on Tru64, it seems the execute bit for 'other'
> > needs to be set on a directory in order edit files within it using vi.
> > 'Nobody' and 'nogroup' also appear to be special.
> 
> read all about the "no_root_squash" option

I understand that.  The thing that makes them special is that aside from
nobody and nogroup, the ownership of the directory has no impact on my
ability to edit a file in that directory.  Besides that, I'm not editing
as root.  If neither nobody or nogroup owns the directory, the execute
bit must be set for 'other' (chmod o+x) or no files in that directory
can be edited.

> As for your problem accessing files in the directory
> 
> drwxr-x---  2 root     system  4096 Dec 22 08:22 d/
> 
> as an unprivileged user on group 'kmw', the solution is obvious:
> 
> 'chgrp kmw d'
> 
> or
> 
> chmod a+x d

That's exactly the problem.  The first obvious solution doesn't work.
Your second solution does.  The directory must have the execute bit set
for other, or the the file cannot be edited, no matter who owns the
directory (unless the owner/group is nobody/nogroup).

Skřl

-Ron-

> Cheers,
>   Trond
> 
> > I'm running 2.6.14.3 on Debian Sarge.
> > 
> > For example.
> > 
> > On linux, in directory /db/test:
> > 
> > 1185# ll
> > total 16
> > drwxr-x--x  2 root     kmw     4096 Dec 21 22:39 a/
> > drwxr-x---  2 nobody   kmw     4096 Dec 21 22:39 b/
> > drwxr-x---  2 rpeterso nogroup 4096 Dec 21 22:46 c/
> > drwxr-x---  2 root     system  4096 Dec 22 08:22 d/
> > 
> > where /etc/exports looks like
> > 
> > /db/test  \
> >               depot.p(rw,sync) \
> >               polar.p(rw,sync,insecure_locks)
> > 
> > I mount this on Tru64 like:
> > 
> > mount -o tcp yogi.p:/db/test dbtest
> > 
> > Each directory a,b,c,d has a small text file named 'test':
> > 
> > -rw-rw-r--  1 root kmw 5 Dec 21 22:39 test
> > 
> > As a user in group kmw I can edit this file in directory a, b, and c.  I
> > can't edit the file in directory d.
> > 
> > I understand that Tru64 doesn't send matching credentials with nfs lock
> > requests.  The 'insecure_locks' option seems to help work around
> > permission problems on the files themselves, but doesn't seem to work
> > around the permissions of the owning directory.
> > 
> > It's probably fair to point fingers at Tru64, but it seems unlikely
> > there will be any changes to nfs on that side...
> > 
> > I'm not subscribed the lkml, so cc's are appreciated.
> > 
> > Best.
> > 
-- 
Ron Peterson
Network & Systems Manager
Mount Holyoke College
http://pks.mtholyoke.edu:11371/pks/lookup?search=0xB6D365A1&op=vindex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/