I have a C++ application that summons a server on another machine via the xinetd service on Linux Centos5 64 bit. The summoned process is invoked as root, but I think it may be a root that does not have full capabilities because of what I observe in my application.
In my application, running as root via inetd invocation, I create a new file and link (each initially user root and group root) and then call lchown() successfully on the owner, but it always fails on the group with EPERMS, Operation not permitted. Combining the user and group into a single invocation of lchown() fails similarly.
The code in question in my application is like this:
::lchown("pathnameToFile", uid_t(500), static_cast<unsigned>(-1)); // This line works
::lchown("pathnameToFile", static_cast<unsigned>(-1), gid_t(500)); // This line fails
::lchown("LinkToPathname", uid_t(500), static_cast<unsigned>(-1)); // This line works
::lchown("LinkToPathname", static_cast<unsigned>(-1), gid_t(500)); // This line fails
The newly created files live in as NFS mounted directory with permissions like this after my code runs:
drwxrwxr-x 2 me me 4096 Jun 22 17:33 .
drwxrwxrwx 2 me me 4096 Jun 22 17:33 ..
-rw-rw-r-- 1 me root 33 Jun 22 17:33 pathnameToFile
lrwxrwxrwx 1 me root 8 Jun 22 17:33 LinkToPathname -> pathnameToFile
The gid 500 is the primary group for 'me', the other group being 'wheel'.
> groups
me wheel
From the shell prompt, I can do chgrp logged in as root to group me with no issues.
Why does lchown() behave differently when my application is invoked via inetd? Note that the same application invoked as root via ssh properly sets the group owner of the file. Why is root via ssh different than root via xinetd?