5

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 $?
0

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
exit_group(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
Permissive
[root@host statd]# uname -a
Linux host.example.com 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?

Patrick
  • 61
  • 6
  • 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
  • id works fine as root; can't su to another user to find out. – Patrick Aug 30 '13 at 15:53
  • I had this problem, except in a different context, on CentOS 6. Interactively, the `setuid(uid_t )` call worked, but when the process was started from an Upstart script, it just wouldn't do anything and would not return an error code. I never got to the bottom of the problem. SELinux was "permissive" mode, so that shouldn't have been the problem. I eventually got something to work with `chown user:group executable` and `chmod +s executable`. This worked under Upstart... go figure. – Mark Lakata Aug 27 '14 at 21:51

1 Answers1

1

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.

Patrick
  • 61
  • 6