chown nobody:nogroup = Invalid argument?!?

[Danny Petterson - DK]

Hi Gurus!

Description of the problem:

I have some files/directories in a directory shared using NFS. When the clients create files in this share, they are created with ownership nobody:nogroup. This works fine - however, for some reason some of the files are changed to ownership root:root, making them inaccessable for the clients.

No worries, I thought, just changing it back to nobody:nogroup...

...however...

When I try I get this:

: Invalid Argument

Is it not possible to chown files/dirs to nobody:nogroup?

Thanks in advance.

Kind regards
Danny Petterson

[Matti_Kurkela]

When you're trying to run the "chown nobody:nogroup", are you running it on a NFS client or on the NFS server? Are you root?

If you're root on a NFS client, you usually have *very limited* access to files and directories on NFS-mounted filesystems. Your identity is translated to nobody:nogroup whenever you try to access NFS filesystems: you can only read world-readable files, and you can only write to world-writable directories and files.

This prevents someone who has managed to crack root access on a NFS client from getting root access on other clients and the NFS server too: otherwise, it would be possible to write a small program that modifies system settings to allow full access to an intruder, set it to have "setuid root" permissions, and then trick someone or something on the NFS server or the other clients to run it.

To chown a root-owned file in a NFS-shared filesystem, you must run the chown command on the NFS server: there the filesystem is a normal local filesystem, and the root access works normally.

-----

But the very fact that the "nobody:nogroup" user owns files in your NFS environment is a sign of poor security practices. I guess you're probably running some application on your clients as root.

You should instead set up a group and make sure it's associated with the same GID number in your NFS server and all the clients. All the users that require access to the shared directory should be made members of that group. A user can belong to multiple groups simultaneously, but a file cannot (without the use of ACLs).

If the application needs to run as a daemon, you should also create a specific user account for it, and likewise make sure the UID of that user is the same in both the NFS server and all the clients.

MK

[Danny Petterson - DK]

Thanks for the quick response.

The chmod was tryied as root, on the directory itself, not from the client using NFS.

The client-user accessing these shares are the root-user from the Linux-prompt on VMWare ESX Servers (used for templates).

Thanks

Yours
Danny

[Dennis Handly]

It looks like you can't do that even if on the local system, from tusc:
chown("dummy_99", -2, -2) .. ERR#22 EINVAL

[EINVAL] Either owner or group is greater than or equal to UID_MAX, or is an illegal negative value.

[Matti_Kurkela]

So, the NFS share contains sysadmin tools, templates and the like. I see why this should be accessible (and potentially writable) by the NFS clients' root.

Plan B would be to make the share safe for root access, and then remove the root -> nobody mapping from that share.

The first step would be to mount the filesystem containing the share with the "nosuid" mount option at the NFS server side. Ideally, the share would have to be a separate filesystem. (If the NFS server's filesystem supports it, a "nodev" option would be a good thing too; but HP-UX does not seem to support it.)

This is to make it harder for an unauthorized user to gain root on the NFS server even if s/he already has root access on one of the NFS clients.


The second step would be to allow the NFS clients' root user(s) to access the NFS filesystem as root. In HP-UX, this can be done with the "anon=0" option in /etc/exports (or in /etc/dfs/dfstab in HP-UX 11.31).

In HP-UX 11.31, you can specify "nosuid" in the /etc/dfs/dfstab too: that will cause the NFS server to silently block any attempts to set the setuid or setgid bits.

(My assumption that your NFS server is a HP-UX system comes from the fact that you're posting to the HP-UX section of the forums; if your NFS server is a Linux system, you'll want to use the "no_root_squash" option in /etc/exports instead of the above-mentioned HP-UX-specific options.)


After these steps, the client-created files should be created with ownership root:root, and any root-owned files in the NFS share should be accessible normally for the root user(s) on the NFS clients.

MK