nfs insecure_locks / Tru64 behaviour

[Ron Peterson]

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
-
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/