From: Ron Peterson <rpeterso@MtHolyoke.edu>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: nfs insecure_locks / Tru64 behaviour
Date: Thu, 22 Dec 2005 20:39:34 -0500 [thread overview]
Message-ID: <20051223013933.GB22949@mtholyoke.edu> (raw)
In-Reply-To: <1135293713.3685.9.camel@lade.trondhjem.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 2735 bytes --]
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
next prev parent reply other threads:[~2005-12-23 1:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 13:36 nfs insecure_locks / Tru64 behaviour Ron Peterson
2005-12-22 23:21 ` Trond Myklebust
2005-12-23 1:39 ` Ron Peterson [this message]
2005-12-23 1:45 ` Trond Myklebust
2005-12-23 2:21 ` Ron Peterson
2005-12-23 2:32 ` Ron Peterson
2005-12-23 8:37 ` Trond Myklebust
2005-12-23 13:38 ` Ron Peterson
2005-12-23 13:50 ` Trond Myklebust
2005-12-23 14:39 ` Ron Peterson
2005-12-23 15:00 ` Trond Myklebust
2005-12-23 18:10 ` Bernd Eckenfels
2005-12-23 20:58 ` Trond Myklebust
2005-12-23 21:41 ` Bernd Eckenfels
2005-12-23 22:00 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051223013933.GB22949@mtholyoke.edu \
--to=rpeterso@mtholyoke.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox