After recently updating to CentOS 6.4, two machines have setuid() restrictions which act like either capabilities or selinux, however both are disabled. E.g. the following fails:

[root@host statd]# perl -e 'use POSIX; POSIX::setuid(99);system("id")'
[root@host statd]# echo $?

When it should return something like:

host:~# perl -e 'use POSIX; POSIX::setuid(99);system("id")'
uid=99(nobody) gid=0(root) groups=99(nobody),0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Strace'ing the invocation of perl, the setuid() call succeeds, however the system() child immediately exits, like it was terminated by selinux or similar. However there's no log entry in /var/log/audit/audit.log, even after semodule -DB.

setuid32(99)                            = 0
getuid32()                              = 99
geteuid32()                             = 99
pipe([3, 4])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7705728) = 10073
close(4)                                = 0
rt_sigaction(SIGINT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
waitpid(10073, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], 0) = 10073
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, NULL, 8) = 0
read(3, "\r\0\0\0", 4)                  = 4
close(3)                                = 0

This problem became evident after the first reboot as nfs.statd failed with "Failed to access local netconfig database: Netconfig database not found". And rpc.rquotasd failed because "RPC: server localhost requires stronger authentication."

The nfs.statd problem can be fixed by running it as root (chown root:root /var/lib/nfs/statd ). Running everything on the machine as root does not seem like a great workaround. ;)

Trying to su to another account also does not work:

[root@host ~]# su - jboss
su: warning: cannot change directory to /opt/jboss: Permission denied
su: /bin/bash: Permission denied
[root@host ~]# su jboss
su: /bin/bash: Permission denied

Basic system info follows:

[root@host statd]# getenforce
[root@host statd]# uname -a
Linux 2.6.32-358.14.1.el6.i686 #1 SMP Tue Jul 16 21:12:30 UTC 2013 i686 i686 i386 GNU/Linux
[root@host statd]# cat /etc/redhat-release
CentOS release 6.4 (Final)
[root@host statd]# getcap /usr/bin/perl
/usr/bin/perl =

What could be causing this when it's apparently not selinux or linux capabilities?

  • Has this machine been running in permissive mode all the time or did you change it for testing? – dawud Aug 30 '13 at 11:02
  • this should work even with enforcing with targeted policy.... there is no selinux problem, definitely. you can see it in strace – GioMac Aug 30 '13 at 11:25
  • works for me in same version, but x86_64 – GioMac Aug 30 '13 at 11:28
  • The fault appears in disabled, permissive, and enforcing. Originally the box was running in enforcing; switched to the other selinux modes for testing. – Patrick Aug 30 '13 at 11:31
  • Does the id command work at all? – Michael Hampton Aug 30 '13 at 14:44
up vote 1 down vote accepted

Somehow the upgrade process changed the perms on / to:

[root@host ~]# ls -alZ /
drw-r--r--. 42374 5031 system_u:object_r:root_t:s0      .
drw-r--r--. 42374 5031 system_u:object_r:root_t:s0      ..

Which was fixed with a

chown root:root / && chmod 755 /

A big help in narrowing the error space was instead running

strace perl -e 'use POSIX; POSIX::setuid(99);exec("id")'

Which showed perl's execve() call failing each time with EACCES as it tried all the $PATH dirs.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.