public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ron Peterson <rpeterso@MtHolyoke.edu>
To: linux-kernel@vger.kernel.org
Subject: nfs insecure_locks / Tru64 behaviour
Date: Thu, 22 Dec 2005 08:36:23 -0500	[thread overview]
Message-ID: <20051222133623.GE7814@mtholyoke.edu> (raw)

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.

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

             reply	other threads:[~2005-12-22 13:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-22 13:36 Ron Peterson [this message]
2005-12-22 23:21 ` nfs insecure_locks / Tru64 behaviour Trond Myklebust
2005-12-23  1:39   ` Ron Peterson
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=20051222133623.GE7814@mtholyoke.edu \
    --to=rpeterso@mtholyoke.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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