jv@mhres.mh.nl (Johan Vromans) (07/27/88)
On my system, HP9000/320 running HP-UX 5.3, I encounter the following problem: I have a server configured under inetd, with the following line in /etc/inetd.conf : smtp stream tcp nowait mailer /etc/smtpd smtpd This program reads a smtp message from stdin, and then execs a mail delivery program. This program runs setgid 'mail'. This program creates a file in /usr/mail/, and calls chown(2) to change ownership to someone else (e.g. the recipient of the mail). The 'chown'-call fails with EPERM: "Not owner". But the file which was created in /usr/mail/ has owner 'mailer' and group 'mail' - just as can be expected. So - the program CREATES a file (this makes the program owner by definition), and then gets error NOT OWNER when it tries to chown it. As far as I have tried, this only happens when the program is run from the inetd. The problem disappears when I have the program run as user 'root' (change "mailer" into "root" in the /etc/inetd.conf line). Although I found a good work-around (running it as user 'root') I wonder what is happening here. Any suggestions? -- Johan
rml@hpfcdc.HP.COM (Bob Lenk) (07/28/88)
By default HP-UX follows the System V semantics of allowing any user to
chown(2) any file (s)he owns. However, this can be restricted with the
privileged group facility. If your system is set up this way, you would
get the EPERM error as described (and as on a BSD or V7 system). To check
what privileged groups are set up on your system, type:
getprivgrp
The output in the default configuration is:
global privileges: CHOWN
If CHOWN does not appear in the output, the system permits only the
superuser to chown files (except that any process can change the group
of a file it owns to another group in its group list). In this case you
could permit group "mail" to have chown privilege as well. See
getprivgrp(1) and setprivgrp(1m).
Bob Lenk
{ihnp4, hplabs}!hpfcla!rml
rml%hpfcla@hplabs.hp.comdwall@hpindda.HP.COM (Darren Wall) (07/28/88)
> The 'chown'-call fails with EPERM: "Not owner". But the file which was > created in /usr/mail/ has owner 'mailer' and group 'mail' - just as > can be expected. ....... > Although I found a good work-around (running it as user 'root') I wonder > what is happening here. > > Any suggestions? Yes, try looking at the command /etc/setprivgrp. It allows a super-user to allow group access to kernel capabilities (specifically, RTPRIO, MLOCK, and CHOWN). By default, the super-user has these capabilities, other users don't, but can be allowed by use of the setprivgrp command. Executing the command `/etc/setprivgrp mail CHOWN` should make this work for you. This could be put in your /etc/rc so that it is executed every time you boot. Darren Wall Information Networks Division Hewlett-Packard Company
jin@hplabsz.HPL.HP.COM (Tai Jin) (07/29/88)
Re: chown fails with EPERM You might check to see if you have "setprivgrp -g CHOWN" in /etc/rc (although I think it is the default and you have to explicitly turn it off). This allows users to give away files that they own. The root user can always give away files. ...tai
jv@mhres.mh.nl (Johan Vromans) (07/31/88)
From article <5570054@hpfcdc.HP.COM>, by rml@hpfcdc.HP.COM (Bob Lenk): > To check > what privileged groups are set up on your system, type: > > getprivgrp > > The output in the default configuration is: > > global privileges: CHOWN > Output from shell: $ getprivgrp global privileges: CHOWN $ I received a number of responses about the set/getprivgrp facility. Of course I checked my system configuration thouroughly before submitting the problem to the net. As could be seen from the problem description, the mail delivery program (and thus the chown feature) works correctly, except when the program is invoked from inetd with user "mailer". -- Johan