Date: Sun, 21 Feb 2021 09:39:40 +1100 From: Chris Johns <chrisj@rtems.org> To: Rick Macklem <rmacklem@uoguelph.ca>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: sys/fs/nfsclient ACCESS attributes with RTEMS Message-ID: <5f66e68f-2979-dd14-f8f4-ee2bed0a5f43@rtems.org> In-Reply-To: <YQXPR0101MB09680A67466B2FE37726CFA3DD839@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <0e14503a-ca7b-cd0f-6472-289fc9ac301b@rtems.org> <YQXPR0101MB09680A67466B2FE37726CFA3DD839@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21/2/21 3:13 am, Rick Macklem wrote:
> Chris Johns wrote:
>> I have made some progress in porting the FreeBSD kernel NFS client file system
>> to RTEMS. The connection to an NVFv4 server is stable and I can change
>> directories, list directories and read files. I however cannot make a directory.
>> I get a permissions error. This is the fragment of traffic showing the error:
>>
>> 10.10.5.45 -> 10.10.5.4 NFS 246 V4 Call Access ACCESS FH: 0xbb937afe, [Check: RD
>> LU MD XT DL XE]
>> 10.10.5.4 -> 10.10.5.45 NFS 350 V4 Reply (Call In 72) Access ACCESS, [NOT
>> Supported: XE], [Access Denied: MD XT DL], [Allowed: RD LU]
> For whatever reason, the client only has read/lookup access to 0xbb937afe (presumably
> a directory).
>
>> 10.10.5.45 -> 10.10.5.4 NFS 282 V4 Call Lookup LOOKUP DH: 0xbb937afe/read_write_test
>> 10.10.5.4 -> 10.10.5.45 NFS 342 V4 Reply (Call In 74) Lookup LOOKUP Status:
>> NFS4ERR_NOENT
>> 10.10.5.45 -> 10.10.5.4 NFS 282 V4 Call Lookup LOOKUP DH: 0xbb937afe/read_write_test
>> 10.10.5.4 -> 10.10.5.45 NFS 342 V4 Reply (Call In 76) Lookup LOOKUP Status:
>> NFS4ERR_NOENT
>> 10.10.5.45 -> 10.10.5.4 NFS 358 V4 Call Create CREATE
>> 10.10.5.4 -> 10.10.5.45 NFS 210 V4 Reply (Call In 78) Create CREATE Status:
>> NFS4ERR_ACCESS
>>
>> The server is set up for an NFSv4 export and I have `no_squash_root` set for
>> testing. There is no security enabled (nfs@...). The RTEMS client mount options are:
> Since "no_quash_root" doesn't exist on FreeBSD NFS servers (implemented with the
> -maproot export option on FreeBSD), I'll assume a non-FreeBSD server.
Yes. I am testing against Linux and FreeBSD and as you point out the option was
in the Linux server. You will might be pleased to know the RTEMS clients fails
the same way with both servers.
> --> As such, I have no idea why the access is limited. (mode bits, ACL,...?).
>
> If you test against a FreeBSD server, you can "sysctl vfs.nfsd.debuglevel=4" and
> make it pretty chatty to help figure out what is going on.
Thanks, I will have a look. I have isolated a potential reason. The FreeBSD
client has this in the RPC header:
Credentials
Flavor: AUTH_UNIX (1)
Length: 32
Stamp: 0x5e72fba7
Machine Name: ruru
length: 4
contents: ruru
UID: 0
GID: 0
Auxiliary GIDs (2) [0, 5]
GID: 0
GID: 5
and my RTEMS client has:
Credentials
Flavor: AUTH_UNIX (1)
Length: 20
Stamp: 0x21dae501
Machine Name: <EMPTY>
length: 0
contents: <EMPTY>
UID: 65536
GID: 0
Auxiliary GIDs (0)
I am looking at the RPC code to see where this is set up but it is still not
obvious. I am currently looking over auth_unix.c to see what I might be missing.
Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5f66e68f-2979-dd14-f8f4-ee2bed0a5f43>