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
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.
man 5 exports
read all about the "no_root_squash" option
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
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.
>
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
On Thu, 2005-12-22 at 20:39 -0500, Ron Peterson wrote:
> > 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).
Why wouldn't the chgrp solution work? Isn't /etc/groups on the client
and server in sync?
Cheers,
Trond
On Fri, Dec 23, 2005 at 02:45:25AM +0100, Trond Myklebust wrote:
> On Thu, 2005-12-22 at 20:39 -0500, Ron Peterson wrote:
> > > 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).
>
> Why wouldn't the chgrp solution work? Isn't /etc/groups on the client
> and server in sync?
Yep.
Why it doesn't work .. I dunno. My current best guess is that the
manner in which the insecure_locks option in /etc/exports is applied to
directories isn't quite right.
Best.
--
Ron Peterson
Network & Systems Manager
Mount Holyoke College
http://pks.mtholyoke.edu:11371/pks/lookup?search=0xB6D365A1&op=vindex
On Thu, Dec 22, 2005 at 09:21:26PM -0500, rpeterso wrote:
> On Fri, Dec 23, 2005 at 02:45:25AM +0100, Trond Myklebust wrote:
> > On Thu, 2005-12-22 at 20:39 -0500, Ron Peterson wrote:
> > > > 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).
> >
> > Why wouldn't the chgrp solution work? Isn't /etc/groups on the client
> > and server in sync?
>
> Yep.
>
> Why it doesn't work .. I dunno. My current best guess is that the
> manner in which the insecure_locks option in /etc/exports is applied to
> directories isn't quite right.
BTW, the behaviour is that all files appear to be locked. In vi, for
example, when I try to edit the file 'test' below, it says:
"test" [FILE BEING MODIFIED BY ANOTHER PROCESS] 1 line, 31 characters
on tru64 alpha:
% ls -al
total 12
drwxrwx--- 2 root kmw 4096 Dec 22 20:22 .
drwxr-xr-x 6 root system 4096 Dec 22 08:22 ..
-rw-rw-r-- 1 root kmw 31 Dec 22 21:27 test
% groups
accntmgr kmw ...
Best.
--
Ron Peterson
Network & Systems Manager
Mount Holyoke College
http://pks.mtholyoke.edu:11371/pks/lookup?search=0xB6D365A1&op=vindex
On Thu, 2005-12-22 at 21:21 -0500, Ron Peterson wrote:
> Why it doesn't work .. I dunno. My current best guess is that the
> manner in which the insecure_locks option in /etc/exports is applied to
> directories isn't quite right.
insecure_locks has nothing at all to do with directories. It has to do
with the NLM protocol, which is used by NFSv2/v3 to implement posix
locks.
Directory locking is an entirely separate matter, and is not part of the
NFS protocol (the server will take care of locking the directory when it
needs to modify it without any extra help from the client).
IOW: your problem here has nothing to do with insecure_locks, and
everything to do with your setup. Please double-check that the gid
mappings for the group 'kwc' in /etc/groups match on the client and
server, and note that the default root squashing means that your root
account will get mapped to the user with uid -2 and gid=-2
Cheers,
Trond
On Fri, Dec 23, 2005 at 09:37:55AM +0100, Trond Myklebust wrote:
> On Thu, 2005-12-22 at 21:21 -0500, Ron Peterson wrote:
>
> > Why it doesn't work .. I dunno. My current best guess is that the
> > manner in which the insecure_locks option in /etc/exports is applied to
> > directories isn't quite right.
>
> insecure_locks has nothing at all to do with directories. It has to do
> with the NLM protocol, which is used by NFSv2/v3 to implement posix
> locks.
> Directory locking is an entirely separate matter, and is not part of the
> NFS protocol (the server will take care of locking the directory when it
> needs to modify it without any extra help from the client).
>
> IOW: your problem here has nothing to do with insecure_locks, and
> everything to do with your setup. Please double-check that the gid
> mappings for the group 'kwc' in /etc/groups match on the client and
> server, and note that the default root squashing means that your root
> account will get mapped to the user with uid -2 and gid=-2
The gid's of the kmw group match on both sides. The problem happens
whether root squashing is on or off. Unless the execute bit for 'other'
is turned on for the parent directory, the file appears to be locked
when being accessed from the nfs client (tru64) side.
My theory may be wrong, but the problem still exists.
Best.
--
Ron Peterson
Network & Systems Manager
Mount Holyoke College
http://pks.mtholyoke.edu:11371/pks/lookup?search=0xB6D365A1&op=vindex
On Fri, 2005-12-23 at 08:38 -0500, Ron Peterson wrote:
> The gid's of the kmw group match on both sides. The problem happens
> whether root squashing is on or off. Unless the execute bit for 'other'
> is turned on for the parent directory, the file appears to be locked
> when being accessed from the nfs client (tru64) side.
>
> My theory may be wrong, but the problem still exists.
Possibly, but that sounds like it might be a tru64 bug. As you can see,
a Linux client has no such problems:
[trondmy@longyearbyen trondmy]$ id
uid=520(trondmy) gid=100(users) groups=10(wheel),100(users)
[trondmy@longyearbyen trondmy]$ ls -al
total 0
drwxr-xr-x 5 trondmy users 36 Dec 23 08:44 .
drwxr-xr-x 3 root root 20 Jun 17 2005 ..
drwxr-x--- 2 root users 18 Dec 23 08:47 d
drwxr-xr-x 8 root root 68 Dec 5 01:11 gnurr
drwxr-xr-x 2 trondmy users 30 Nov 23 10:38 tmp
[trondmy@longyearbyen trondmy]$ ls -al d
total 4
drwxr-x--- 2 root users 18 Dec 23 08:47 .
drwxr-xr-x 5 trondmy users 36 Dec 23 08:44 ..
-rw-r--r-- 1 root root 6 Dec 23 08:47 hello
[trondmy@longyearbyen trondmy]$ cat d/hello
hello
Cheers,
Trond
On Fri, Dec 23, 2005 at 02:50:12PM +0100, Trond Myklebust wrote:
> On Fri, 2005-12-23 at 08:38 -0500, Ron Peterson wrote:
> > The gid's of the kmw group match on both sides. The problem happens
> > whether root squashing is on or off. Unless the execute bit for 'other'
> > is turned on for the parent directory, the file appears to be locked
> > when being accessed from the nfs client (tru64) side.
> >
> > My theory may be wrong, but the problem still exists.
>
> Possibly, but that sounds like it might be a tru64 bug. As you can see,
> a Linux client has no such problems:
Not unlikely. I was hoping it was a bug that the insecure_locks options
was meant to work around. Perhaps that's not possible. :(
Sk?l.
--
Ron Peterson
Network & Systems Manager
Mount Holyoke College
http://pks.mtholyoke.edu:11371/pks/lookup?search=0xB6D365A1&op=vindex
On Fri, 2005-12-23 at 09:39 -0500, Ron Peterson wrote:
> On Fri, Dec 23, 2005 at 02:50:12PM +0100, Trond Myklebust wrote:
> > On Fri, 2005-12-23 at 08:38 -0500, Ron Peterson wrote:
> > > The gid's of the kmw group match on both sides. The problem happens
> > > whether root squashing is on or off. Unless the execute bit for 'other'
> > > is turned on for the parent directory, the file appears to be locked
> > > when being accessed from the nfs client (tru64) side.
> > >
> > > My theory may be wrong, but the problem still exists.
> >
> > Possibly, but that sounds like it might be a tru64 bug. As you can see,
> > a Linux client has no such problems:
>
> Not unlikely. I was hoping it was a bug that the insecure_locks options
> was meant to work around. Perhaps that's not possible. :(
As I said, insecure_locks has nothing to do with file access.
Cheers,
Trond
In article <[email protected]> you wrote:
> 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).
Is it a edit problem or a directory-enter problem (i.e. can you do a "cd d"?).
Is it a general file access problem or only with vi (i.e. can do "echo bla >> file")
If it is a vi specific problem maybe the locking is the problem:
The insecure_locks on Linux server is needed, cause Linux NFS Server will
serve lock requests normally only from root users, and True64 requests from
unpriveledged daemon user. This means fctnl locking cannot be done, and this
might be a problem for vi.
Otherwise check that lockd/statd is running on your server.
I dont know how to turn of locking in Tru64 vi (vim: set lock off) or Tru64
mount (linux: nolock).
Gruss
Bernd
On Fri, 2005-12-23 at 19:10 +0100, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > 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).
>
> Is it a edit problem or a directory-enter problem (i.e. can you do a "cd d"?).
>
> Is it a general file access problem or only with vi (i.e. can do "echo bla >> file")
>
> If it is a vi specific problem maybe the locking is the problem:
>
> The insecure_locks on Linux server is needed, cause Linux NFS Server will
> serve lock requests normally only from root users, and True64 requests from
> unpriveledged daemon user. This means fctnl locking cannot be done, and this
> might be a problem for vi.
Huh? No it doesn't. The Linux NLM server requires that the client
authenticate using AUTH_SYS (unless you use insecure_locks), but it
certainly doesn't require you to have root privileges. That would
violate POSIX locking rules.
Cheers,
Trond
On Fri, Dec 23, 2005 at 09:58:40PM +0100, Trond Myklebust wrote:
> Huh? No it doesn't. The Linux NLM server requires that the client
> authenticate using AUTH_SYS (unless you use insecure_locks), but it
> certainly doesn't require you to have root privileges. That would
> violate POSIX locking rules.
Yes, however True64 does not authenticate (properly), thats why you need the
option if you want to do locking.
Gruss
Bernd
--
(OO) -- Bernd_Eckenfels@M?rscher_Strasse_8.76185Karlsruhe.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/
o--o 1024D/E383CD7E eckes@IRCNet v:+497211603874 f:+49721151516129
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
On Fri, 2005-12-23 at 22:41 +0100, Bernd Eckenfels wrote:
> On Fri, Dec 23, 2005 at 09:58:40PM +0100, Trond Myklebust wrote:
> > Huh? No it doesn't. The Linux NLM server requires that the client
> > authenticate using AUTH_SYS (unless you use insecure_locks), but it
> > certainly doesn't require you to have root privileges. That would
> > violate POSIX locking rules.
>
> Yes, however True64 does not authenticate (properly), thats why you need the
> option if you want to do locking.
Sure, however his problem doesn't appear to be related to POSIX/fcntl
locking on the file itself, but rather to access checking on the parent
directory.
Cheers,
Trond