On Mon, 27 Mar 2006, Han Boetes wrote:

> Otto Moerbeek wrote:
> > On Sun, 26 Mar 2006, Han Boetes wrote:
> > > This also seems to be related to the owned of the directory in
> > > which the file exists. IE, if I changed the owner of the file to
> > > the restricted account, my own account -- also member of the nfs
> > > group -- still could write to the file.
> >
> > Can or cannot?
>
> Can.
>
>
> > > This is the matching line in exports:
> > > /home/public/han -maproot=han:nfs marsupilami
> >
> > I am almost able to reproduce:
> >
> > I can edit the file (using vi or redirection form the shell) But
> > a setattr call fails, I cannot touch(1) the file, for example.
> >
> > For some reason your test generates a setattr call, which is
> > normally not done for writing a file.
>
> Yes you are right. I was unclear on that part. Since the latest
> update to the linux kernel -- 2.6.16 -- the restricted account
> could no longer write to the file.
>
> Previous released did allow writing, but not to use setattr.
>
> I'll reopen the bugreport for Linux as well.
>
> Always remarkable the way that both NFS implementations bite each
> other. For example the SUN implementation does allow setattr.
>
> What is the reason behind disallowing setattr?

I'll explain a bit. setattr can be used to modify various attributes
of a file: time stamps and size for example.

The utimes(2) syscall allows setting timestamps if you're owner or
superuser and it allows setting the timestamps to the current time if
you may write the file.

In the case of NFS, the umodes(2) call issues a setattr NFS request.
The NFS setattr call does not know this "set to current time" case,
and only allows the owner to set the timestamps.

Linux has a hack in its NFS server to allows setting the timestamps
"if close enough to current time". This is a real hack, since it
requires some form of time coherence between server and client.

Anyway, as you already mentioned, the linux client behaviour is a
regression, it issues an setattr call it did not do before.

The touch(1) error I'm seeing is a consequence of my change to
touch.c: previously it used read/write code with all kinds of races to
modify the timestamp if the utimes(2) call failed. That code was
removed and the error reported by utimes(2) is now shown.

I'll have to take a look into Solaris to see how they handle things.

-Otto