I have a kerberized NFS4 setup using EL7.4 that has been working for quite a
long time. Today I started having trouble with permissions from some clients.
I haven't been able to figure out what changed.
It appears though that some requests are being sent as root as so permission
to access is denied.
$ id
uid=22603(orion) gid=22603(orion) groups=22603(orion)
ls -l .Xauthority
-rw-------. 1 orion orion 130 Nov 27 12:59 .Xauthority
$ cat .Xauthority
cat: .Xauthority: Operation not permitted
I tried reverting to sec=sys, but still had problems. Here is a tshark -V
decode of the open request:
Remote Procedure Call, Type:Call XID:0x1379e0da
Fragment header: Last fragment, 236 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0000 1110 1100 = Fragment Length: 236
XID: 0x1379e0da (326754522)
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003)
Program Version: 4
Procedure: COMPOUND (1)
Credentials
Flavor: AUTH_UNIX (1)
Length: 40
Stamp: 0x00418e08
Machine Name: client
length: 17
contents: client
fill bytes: opaque data
UID: 0
GID: 0
Auxiliary GIDs (0)
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Network File System, Ops(5): PUTFH, OPEN, GETFH, ACCESS, GETATTR
[Program Version: 4]
[V4 Procedure: COMPOUND (1)]
Tag: <EMPTY>
length: 0
contents: <EMPTY>
minorversion: 0
Operations (count: 5): PUTFH, OPEN, GETFH, ACCESS, GETATTR
Opcode: PUTFH (22)
filehandle
length: 32
[hash (CRC-32): 0x6fd1a280]
decode type as: unknown
filehandle: 01000681c370d9f027664f269d1025f51329966086b50420...
Opcode: OPEN (18)
seqid: 0x00000000
share_access: OPEN4_SHARE_ACCESS_READ (1)
share_deny: OPEN4_SHARE_DENY_NONE (0)
clientid: 0x69531c5aaefd36d7
owner: <DATA>
length: 24
contents: <DATA>
Open Type: OPEN4_NOCREATE (0)
Claim Type: CLAIM_NULL (0)
Name: .Xauthority
length: 11
contents: .Xauthority
fill bytes: opaque data
Opcode: GETFH (10)
Opcode: ACCESS (3), [Check: RD MD XT XE]
Check access: 0x2d
.... ...1 = 0x01 READ: allowed?
.... .1.. = 0x04 MODIFY: allowed?
.... 1... = 0x08 EXTEND: allowed?
..1. .... = 0x20 EXECUTE: allowed?
Opcode: GETATTR (9)
Attr mask[0]: 0x0010011a (TYPE, CHANGE, SIZE, FSID, FILEID)
reqd_attr: TYPE (1)
reqd_attr: CHANGE (3)
reqd_attr: SIZE (4)
reqd_attr: FSID (8)
reco_attr: FILEID (20)
Attr mask[1]: 0x00b0a23a (MODE, NUMLINKS, OWNER, OWNER_GROUP,
RAWDEV, SPACE_USED, TIME_ACCESS, TIME_METADATA, TIME_MODIFY, MOUNTED_ON_FILEID)
reco_attr: MODE (33)
reco_attr: NUMLINKS (35)
reco_attr: OWNER (36)
reco_attr: OWNER_GROUP (37)
reco_attr: RAWDEV (41)
reco_attr: SPACE_USED (45)
reco_attr: TIME_ACCESS (47)
reco_attr: TIME_METADATA (52)
reco_attr: TIME_MODIFY (53)
reco_attr: MOUNTED_ON_FILEID (55)
[Main Opcode: OPEN (18)]
the server responds with permission denied. Setting no_root_squash allows the
file to catted, though not locked.
I'm at a loss. Some essentially identical clients work fine, some do not.
I've rebooted the server once and the clients many times.
3.10.0-693.5.2.el7.x86_64
nfs-utils-1.3.0-0.48.el7_4.x86_64
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane [email protected]
Boulder, CO 80301 https://www.nwra.com/
On 11/27/2017 04:28 PM, Orion Poplawski wrote:
> I have a kerberized NFS4 setup using EL7.4 that has been working for quite a
> long time. Today I started having trouble with permissions from some clients.
> I haven't been able to figure out what changed.
>
> It appears though that some requests are being sent as root as so permission
> to access is denied.
This appears to be caused by BitDefender anti-virus.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane [email protected]
Boulder, CO 80301 https://www.nwra.com/
On Tue, Nov 28, 2017 at 07:47:57AM -0700, Orion Poplawski wrote:
> On 11/27/2017 04:28 PM, Orion Poplawski wrote:
> > I have a kerberized NFS4 setup using EL7.4 that has been working for quite a
> > long time. Today I started having trouble with permissions from some clients.
> > I haven't been able to figure out what changed.
> >
> > It appears though that some requests are being sent as root as so permission
> > to access is denied.
>
>
> This appears to be caused by BitDefender anti-virus.
Thanks for following up.--b.