Re: NFS Mount and CPFA0A1

Thanks Patrik for the crash course of Unix users and NFS implementation
It is eye opener.

Thanks Richard for the detailed instructions
Our domain/net admin has left early today so I'll take it to him tomorrow
morning.

There are good people on this forum.

Gad

date: Wed, 12 May 2021 14:03:10 +0200
from: Patrik Schindler <poc@xxxxxxxxxx>
subject: Re: NFS Mount and CPFA0A1

Hello Gad,

Am 12.05.2021 um 13:00 schrieb Gad Miron <gadmiron@xxxxxxxxx>:

As to the root issue, He does not understand what you mean by root

allowed

for the NFS share.

In Linux, what he's referring to is called "root_squash". NFS comes from
the Unix world, so a bit of background knowledge might help.

The Unix administrative user (usually called "root") always has user-id 0.

Since NFSv3 and predecessors authenticate access via IP address (to
whitelist hosts for access), and transparently pass the access rights and
uid/gid of objects in the mounted tree, the nfs-client's local security
system is responsible for enforcing access security.

It is crucial to understand that /etc/passwd is *also* just a way of
resolving numeric user-ids to a name. (As administrator, one can effortless
change the ownership of a file to a numeric id, *not listed in
/etc/passwd*! This fact is not related to NFS.)

Example: On hosta, Alice creates a file on a local mountpoint, being
exported via NFS. /etc/passwd associates her name with the userid 500. On
hostb, the NFS export is mounted. Bob is logged in, and by chance has the
user-id 500, because uids are just incremented with every defined user in
/etc/passwd. Bob can now happily do anything with Alice's file as long as
the access-rights (rwx, etc.) permit.

This was why Sun invented NIS back in the day, to have /etc/passwd in sync
on all NFS clients. See
https://en.wikipedia.org/wiki/Network_Information_Service

Back to root_squash: If Alice logs in as root on her machine, and again
creates a file with it's user-id 0, Bob (with his self-installed Linux,
thus having root-access on that box), can again happily do anything with
that root's file as long as the access-rights permit. This was seen as a
gaping security issue. Thus, by convention, NFS-Servers map *accesses* from
clients with user-id 0 to the userid of nobody (signed 16-Bit integer, -1 =
65534). If a remote "root" accesses any file on a NFS export, he in fact
does this as user nobody. The same applies to group-id 0.

Sometimes, this root-access is desired and/or necessary, for netbooting
clients from a read-only export, to have stressless access from VMware ESXi
to NFS backing stores, etc. Thus, NFS-Servers can be instructed to *not*
automatically map root (uid 0) to nobody (uid -1).

Hope this helps to clarify the issue at hand.

(On a side note, IBM i has a similar issue with Object Connect, the
SAVRST* commands. If you run this as QSECOFR on your own ? assumingly rogue
? machine, it's possible to overwrite objects on remote machines: As long
as the QSYS.LIB file's level-id match, and the rogue machine is allowed to
establish an APPC session with the target. No apparent restrictions in /.
And no, access is *not* dependent on user directory entries, seen with
WRKDIRE.)

:wq! PoC



------------------------------


date: Wed, 12 May 2021 12:42:27 +0000
from: Richard Schoen <richard@xxxxxxxxxxxxxxxxx>
subject: Re: NFS Mount and CPFA0A1

On the Windows NFS Share under "Authentication", there should also be a
permissions setting called:

No server authentication - Check that box.

Enable unmapped user access - Check that box

Allow anonymous access - Check that box

Click OK to apply the settings and then see if it works by doing a WRKLNK.

Regards,
Richard Schoen
Web: http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
------------------------------

message: 4
date: Wed, 12 May 2021 14:00:41 +0300
from: Gad Miron <gadmiron@xxxxxxxxx>
subject: Re: NFS Mount and CPFA0A1

Thanks Tsvetan, Richards

Our net admin added user Everyone to the Win directory permissions
(turned out that user Everyone has authority to the other working NFS
shares)
But still no luck (i.e. CPFA0A1)

As to the root issue, He does not understand what you mean by root allowed
for the NFS share.

I'm still plugging at it....

Thanks
Gad

----------------------------------------------------------------------

date: Mon, 10 May 2021 14:22:54 +0000
from: Richard Schoen <richard@xxxxxxxxxxxxxxxxx>
subject: Re: NFS Mount and CPFA0A1

Try adding the Everyone user to the Windows directory permissions for the
share.

Regards,
Richard Schoen
Web: http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
------------------------------


date: Mon, 10 May 2021 10:23:35 +0000
from: Tsvetan Marinov <tsetso.marinov@xxxxxxxxx>
subject: Re: NFS Mount and CPFA0A1

Hi,

I get the same error when the authority on the NFS server are wrong. Do
you have root allowed for the NFS share, do you have correct GID/UID
mapping on the NFS share?

Regards,
Tsvetan