Chown doesn't work in certain circumstances

[Randy Brown_1]

Here's our problem:

A user logs in to one of our systems (HP,Linux, or Sun) The user creates a file in their home directory which is NFS mounted from a network storage device (EMC). They try to chown the file to another user and they get an error telling them they are not the owner. The same behavior occurs if the user tries this same test on a file system mounted from a Linux machine etc. I have attached a small spreadsheet giving the scenarios we tested. Two machines running each platform were tested. It seems like the problem is NIS related. The HP machines are running HP-UX 10.20. The Linux machines are Redhat 7.1 and 7.2. The Sun machines are running Solaris 7 and Solaris 8. I'm sure more information will be required to help solve this, but my brain is a bit fried from working on this this morning. I will gladly supply any additional info you may need to help me. Thank you in advance!

Randy

[Caesar_3]

Hello!

It also depend on how you export and mount.
Because via nfs you can change the user id
by adding number to it, or you didn't give
option for users a root/rw on the nfs point.

Check your export to this machines and the mount that you made on them.

Caesar

[Steven E. Protter]

I think the user numbers are different.

look at /etc/passwd

The various user is on multiple machines right?

Accessed by multiple machines.

So, the OS really works by user number not username.

Hence potential problems.

I solved this by making sure that users get the same user and group numbers on my various machines.

NIS also solves this problem, though I don't know if it can be used in a mixed environment such as yours.

SEP

[Elena Leontieva]

Randy,

The users UID should be consistent across your NFS clients (UNIX servers). If this is not the case in your environment you may have all kinds of problems.

Elena.

[Randy Brown_1]

The UIDs are the same across the board. We are using a master passwd file for all users so that they maintain a consistant UID no matter where they log in. Also the file systems are exported for rw access. That's what's making this so puzzling I'm glad that all of you are coming up with the same questions I did. That helps verify my tests so far. Is there and NIS group or something to that effect that may be coming into play here? It seems to be filesystems being mounted from machines not in the NIS are what are having this trouble. The EMC server, for example, is not in the NIS. Nor is a linux file server. No users log in here so it is not necessary for users to be able to log in there. I'm stumped at this point. I really appreciate any and all input. The more brains, the better.

Thanks again.

Randy

[John Dvorchak]

I am guessing that you have driven your self nuts with export import options and permissions so I am curious about the permissions and owner/group of the exported files system, does it have a sticky bit set? Also after the filesystem is mounted what are the perms etc of the mount point.

I can't duplicate your environment here so all we can do is try to look at things that maybe you haven't already looked at.

[Elena Leontieva]

I wonder if root can chown from any and all systems?

[Randy Brown_1]

Yes, root can chown from any and all systems. The mount points are almost exclusively owned by root but the subdirectories are owned by other users as necessary.

Here are a mount point's permissions:
drwxr-xr-x 7 root root 8192 Jun 30 17:53 shared

A sub directory of shared and it's permissions:
drwxr-xr-x 109 root users 25600 Jul 11 15:56 home

A subdirectory of home and it's permissions
drwxrwxr-x 26 rbrown users 25600 Jul 11 15:50 rbrown

If I log in as user rbrown and touch a file in my home directory, I can't chown to another user.

The file system mounted on /shared is mounted from the EMC network storage server.

Now, another example: I logged in to and HP system that has it's home directory mounted from another HP system.

Perms on /home mounted form HP host
drwxr-xr-x 29 root root 3072 May 29 14:29 home

Perms on subdirectory of /home:
drwxr-xr-x 3 brianm users 1024 Jul 11 20:16 brianm

I touch a file here and try to chown it to another user and I am successful.

Maybe this will help clarify what's happening here. Hopefully, I'll still have hair left when this is all over. If any hair left is still brown, I'll consider that a bonus. :-)

Thanks,

Randy

[Randy Brown_1]

This may shed some light on things. Another SA here chimed in with this:

This might explain it:

"The [...] chown program will change the ownership if the operating system it is
running upon allows it. If you can't change file ownership then it is the
operating system which is restricting you and not the chown program.

"[...] calls the kernel system call chown() just like any other program (e.g.
perl, ruby, etc.) If the OS allows it then it will change the ownership of the
file. Different systems handle this differently. Traditional System V UNIX
systems allow anyone to give a file away to other owners.

"But on most modern systems BSD semantics are followed and only the superuser
can change the ownership of the file.

Excerpt taken from:
GNU Core Utilities Frequently Asked Questions - Why can only root chown files?

http://www.gnu.org/software/fileutils/doc/faq/#Why%20can%20only%20root%20chown%20files%3f

- - -

It may come down to BSD vs. System V semantics. HP-UX is closer to Sys V while
Solaris is descended from BSD and Linux is a mixture of both. The EMC server OS
is a UNIX variant, and based on these findings and information, I'd say there is
a good chance the EMC server OS follows BSD semantics wrt. chown.

Comments? Maybe this is all for naught. Have a wonderful weekend everyone. Thanks for the input. I'll check back on Tuesday for more comments. If I get too bored this weekend, I'll check back sooner.

Randy

[Steven E. Protter]

So far the evidence points to the UID/user number theory.

Of course root can chown any file anywhere, the UID is always zero.

Try this out.

In a secure directory on the hp machine.

copy /etc/passwd to hppasswd
get the passwd file from all of the machines.

Then start running diff commands, compare them, see whats different.

To clarify my response:

user schmobagel is UID 510 on hp

if he's UID 512 on Linux or Solaris, how the system thinks of schmobagel is different from system to system.

NFS does permissions based on the home machine of the exported filesystem.

Example:

schmobagel on Linux has a file on the NFS export called bagel

The UID is 512

From the HP machine on that very same NFS mount, user schmobagel runs the following command

chown root:root bagel

It fails, invalid UID.

Why?

Because the UID in question in this example is 510.

Numbers take precedence over names.

You probably already understood that, and if so, I apologize for insulting your intelligence. My original explanation should have been much more detailed.

SEP