Subject: Re: nfs insecure_locks / Tru64 behaviour
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Bernd Eckenfels <ecki@lina.inka.de>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <E1EprNK-0005ZC-00@calista.inka.de>
References: <E1EprNK-0005ZC-00@calista.inka.de>
Content-Type: text/plain
Date: Fri, 23 Dec 2005 21:58:40 +0100
Message-Id: <1135371520.8555.2.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1403
Lines: 31

On Fri, 2005-12-23 at 19:10 +0100, Bernd Eckenfels wrote:
> In article <20051223013933.GB22949@mtholyoke.edu> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/