Bug or Feature?

[Ralph Grothe]

# uname -srv
HP-UX B.11.00 U
# model
9000/804/K450
# id -nu
root
# touch /tmp/ttt
# ll /tmp/ttt
-rw-r--r-- 1 root sys 0 Jan 16 17:17 /tmp/ttt
# id nobody
uid=4294967294(nobody) gid=4294967294(nogroup)
# chown nobody /tmp/ttt
/tmp/ttt: Invalid argument
# echo $?
1
# chgrp nogroup /tmp/ttt
/tmp/ttt: Invalid argument
# echo $?
1
# ll /tmp/ttt
-rw-r--r-- 1 root sys 0 Jan 16 17:17 /tmp/ttt
# chown nobody:nogroup /tmp/ttt
/tmp/ttt: Invalid argument
# echo $?
1
# ll /tmp/ttt
-rw-r--r-- 1 root sys 0 Jan 16 17:17 /tmp/ttt


I can recall having read in the installation instruction of Apache that you could not run httpd as nobody under HP-UX.
This seems to be the reason, but why?
Would it be possible to usermod nobody account to give it a new UID and GID, or would one screw up other services relying on this strange behavior?

[Sridhar Bhaskarla]

nobody is used only for NFS and is not a regular user. So your chown command won't work.

Not a bug but a feature.

-Sri

[A. Clay Stephenson]

Hi Ralph:

I won't go into the why's but you need to create a user www and a group www. You proably already have a user www.

Then in httpd.conf add:
User www
Group www

You shoulkd then be able to start httpd without problems.

[James A. Donovan]

If the server in question also acts as an NFS server, changing the uid/gid of the nobody account could possibly screw up clients trying to connect.

...here's another thread on the "nobody" account

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x1b9a663ce855d511abcd0090277a778c,00.html

[Ralph Grothe]

Hi Sridhar, hi Jim,

I was already aware that the main purpose of a nobody account derrives from the mapping needs of NFS.
But this to me doesn't look like sufficient evidence against chowning files to this account.
Please, have a look of how fine this works on the OS of the Network File System's inventors viz. Sun Microsystems :

# uname -srv
SunOS 5.7 Generic_106541-11
# id
uid=0(root) gid=1(other)
# id nobody
uid=60001(nobody) gid=60001(nobody)
# touch /tmp/ttt
# ls -l /tmp/ttt
-rw-r----- 1 root other 0 Jan 17 10:57 /tmp/ttt
# chown nobody /tmp/ttt
# ls -l /tmp/ttt
-rw-r----- 1 nobody other 0 Jan 17 10:57 /tmp/ttt
# chgrp nobody /tmp/ttt
# ls -l /tmp/ttt
-rw-r----- 1 nobody nobody 0 Jan 17 10:57 /tmp/ttt


Since this works fine under Solaris 2.7 the restrictions regarding HP-UX's nobody account to me seem to be a bug rather than a feature.

[Stefan Farrelly]

Ralph,

I think the problem is the way the nobody userid is setup on your Sun and HP boxes - they are different.

On an HP nobody is setup as;
nobody:*:-2:60001::/:

Your Sun box shows that it has a hardset uid of 60001, not so on your HP. The HP uses a sort of random id which is why you cant change it on your ttt file.
On an HP you can do; chown 6001 ttt and it works fine, so if you change the nobody userid in the password file to a hardset of 6001, like your Sun, it will work. I dont know what other implications it will have for NFS etc, you will need to try it out.

[harry d brown jr]

Ralph,

I admit I didn't read your question as I saw the respondees already gave you answers. What I want to state, is thaqt the term "bug" is harsh, let's call it "opportunity for enhancements".


live free or die
harry

[Sridhar Bhaskarla]

Hi Ralph,

I didn't really compare it with other OSes as my default scope limits to HP.

Below is the excerpt from exportfs man page.

--->
The default value for uid is the user ID of user
nobody. If user nobody does not exist, the value -2 is
used. Setting the value of anon to -1 disables
anonymous access.
<-----

So, it may not be a problem if you are careful enough to use exportfs options. But people like me wouldn't want to change what's already there. My answer was that this particular user is intended for NFS and HP may not like to change it's feature.

-Sri

[James A. Donovan]

I would suspect that the reason you're getting the errors is that the value of UID_MAX on your system is 2147483647. A glance at the chown.2 manpage reveals that neither uid or guid may be set higher than this constant.

The reason the id command shows the uid and guid to be a large positive number and not -2 probably has to do with how negative numbers are represented in binary to a computer...I'd go into it more, but to be honest, it's been several years since I've had to do that sort of proof, and I don't think I could explain it very well.

[Bill Hassell]

A user ID is always numeric and except for NFS where -1 and -2 are defined, a user ID less than 0 is invalid. Note that the actual user name (nobody) is just a crutch for humans. chown simply translates nobody into -2 (via the passwd file) and then performs the ownership change with the number -2, which is invalid since the field is defined as a positive integer only.