Phil Pennock via Exim-users <exim-users@???> (Mi 30 Jan 2019 03:00:25 CET):
> On 2019-01-29 at 10:30 +0100, Heiko Schlittermann via Exim-users wrote:
> > - The tcpdump show a V4 SETATTR, but only for the owner (I'd have
> > expected the group too), AND the owner is numerical, not user@domain,
> > as I would have expected. The pcap file is attached.
>
> It's showing a GETATTR, not a SETATTR, according to my tcpdump. I just
> installed:
> tcpdump version 4.9.2
> libpcap version 1.9.0-PRE-GIT
> and that's unchanged.
>
> NFS request xid 281459612 216 getattr fh 0,0/22
> NFS reply xid 281459612 reply ok 64 getattr ERROR: Permission denied
> (connection close)
Talking about the dump I atteched? There I get *using tshark*
1 0.000000 192.168.96.41 → 192.168.96.220 NFS 274 V4 Call SETATTR FH: 0x95636125
2 0.000306 192.168.96.220 → 192.168.96.41 NFS 122 V4 Reply (Call In 1) SETATTR Status: NFS4ERR_ACCESS
3 0.000396 192.168.96.41 → 192.168.96.220 TCP 54 718 → 2049 [ACK] Seq=221 Ack=69 Win=1483 Len=0
..
> In this case, GETATTR with major/minor devices of 0 and file descriptor
> 22 is issued, then you get permission denied on just the getattr, so the
> OS isn't getting as far as failing at the chown (or this happened
> after the chown? Incomplete trace, can't tell.)
And yes, tcpdump shows the same dump in another way:
17:05:25.648682 IP 192.168.96.41.718 > 192.168.96.220.2049: Flags [P.], seq 2803392546:2803392766, ack 1363314097, win 1483, length 220: NFS request xid 281459612 216 getattr fh 0,0/22
17:05:25.648988 IP 192.168.96.220.2049 > 192.168.96.41.718: Flags [P.], seq 1:69, ack 220, win 65535, length 68: NFS reply xid 281459612 reply ok 64 getattr ERROR: Permission denied
17:05:25.649078 IP 192.168.96.41.718 > 192.168.96.220.2049: Flags [.], ack 69, win 1483, length 0
Whom to trust more?
(Actually I used wireshark)
--
Heiko
