Bug 6256
Summary: | nfs group permissions don't work right since 2.6.16 | ||
---|---|---|---|
Product: | File System | Reporter: | Han Boetes (han) |
Component: | NFS | Assignee: | Trond Myklebust (trondmy) |
Status: | REJECTED INVALID | ||
Severity: | normal | ||
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.16 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | sudo tcpdump -s9000 -c100 -w file -Nt udp port 2049 |
Description
Han Boetes
2006-03-20 13:40:31 UTC
Booting what with the previous kernel? The client? The server? Which version of NFS? I certainly have no problems on NFSv4/v3/v2 on a Linux client against a Solaris server. Linux nfs3 is the client. OpenBSD nfs3 is the server. What are the owner+permissions on the parent directory /nfs? ~% l /home/ G public drwxr-xr-x 4 root nfs 512 Feb 5 15:00 public ~% l /home/public G han drwxr-xr-x 23 han nfs 1.5K Mar 20 09:38 han Remember... I don't have to change anything but to reboot with the 2.6.16 kernel instead of the 2.6.15.6 kernel to reproduce this. Nothing else changes. I'm still not able to reproduce against my servers. Could you send me a binary tcpdump of what happens when you do "echo foo >/..." from the restricted account? Use something like tcpdump -w /tmp/foo.dmp -s 9000 host server and port 2049 Then send /tmp/foo.dmp Better use this tcpdump command: ~% sudo tcpdump -s9000 -c100 -Nt udp port 2049 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 9000 bytes IP marsupilami.1980904077 > firewall.nfs: 116 getattr fh 0,7/-1701588781 IP firewall.nfs > marsupilami.1980904077: reply ok 112 getattr REG 664 ids 1000/3000 sz 0 IP marsupilami.1997681293 > firewall.nfs: 120 access fh 0,7/-1701588781 002d IP firewall.nfs > marsupilami.1997681293: reply ok 120 access c 000d IP marsupilami.2014458509 > firewall.nfs: 144 setattr fh 0,7/-1701588781 IP firewall.nfs > marsupilami.2014458509: reply ok 144 setattr ERROR: Operation not permitted ~% cat ./test #!/bin/sh echo foo > /mnt/nfs/nowplaying ~% sudo -u bascuppen ./test ./test[2]: cannot create /mnt/nfs/nowplaying: Operation not permitted ...which shows us that the server is rejecting our SETATTR call, but not why. Please could you either send a binary tcpdump, or else use 'tethereal' with the '-V' flag set in order to get full output for the SETATTR. Created attachment 7619 [details]
sudo tcpdump -s9000 -c100 -w file -Nt udp port 2049
That looks like a server bug to me: The ACCESS call shows that we are supposed to be able to read, modify and extend the file, however when the client tries to do a SETATTR to set the time, then the server refuses. Could you try to do 'touch /mnt/nfs/nowplaying' using the 2.6.15.6 client (the one that 'works')? I'll bet that fails with the same error. Hmmm you are right. Odd. I'll ask the OpenBSD developers. Otto Moerbeek wrote: > For some reason your test generates a setattr call, which is normally > not done for writing a file. He hits the nail on the head here. Since 2.6.16 Linux nfs client uses setattr while writing to a file. And that is new and unusual behaviour. Ted Unangst wrote: > this [using touch does not work, while writing does] is normal. > setattr only works if you are the owner of the file. Why the client > has suddenly decided that it needs to do a setattr when > it didn't yesterday is beyond me. He is bullshitting. SETATTR calls to set the timestamp are legal whenever and wherever as long as you have write permissions to the file. We changed the behaviour precisely _because_ we were previously incompliant with respect to the POSIX and Single UNIX Spec behaviour on open(O_CREAT). If OpenBSD isn't willing to accept SETATTR to change the timestamp on files for which the user has write permissions, then I suggest you change servers to something that is compliant with the NFS spec. Closing bug as it appears to be an OpenBSD server issue. |