Bugzilla – Bug 1058
passing arguments with enabled log_subcmds
Last modified: 2023-09-20 04:51:03 MDT
We are using sudo on Virtuozzo 7 which is based on CentOS 7. We noticed that if we turn on subshell logging, containers can no longer be started completely. When the container starts, tasks are executed to allocate resources to the container. The network configuration is also assigned here. The containers start but scripts that assign the IP, for example, do not work. We found that the problem no longer exists if we switch off logging with log_subcmds. sudo vzctl restart xxxxxxxxx Restart the Container Stopping the Container ... Container was stopped Unmount image: /xxxxxxxxx/root.hdd (190) Container is unmounted Starting Container ... Mount image: /xxxxxxxxx/root.hdd Container is mounted Setting permissions for image=/xxxxxxxxx/root.hdd Os release: 4.15.0 Turn userquota on Setting permissions for image=/xxxxxxxxx/root.hdd CPU limit: 377,4% Set up iolimit: 78643200 Set up iopslimit: 500 Setting devices Adding ip address(es): xxxxxxxxx sudo: argv[0] passt nicht, »/sbin/ifdown« wurde erwartet, »venet0« erhalten main: line 790: 14 Killed ifdown ${VENET_DEV} > /dev/null 2>&1 Setting quota ugidlimit: 250 Set hostname: xxxxxxxxx sudo: Pfadname passt nicht, »/bin/which« wurde erwartet, »/bin/dash« erhalten sudo: argv[0] passt nicht, »/bin/which« wurde erwartet, »/bin/sh« erhalten sudo: argv[1] passt nicht, »resolvconf« wurde erwartet, »/bin/which« erhalten sudo: argv[2] passt nicht, »(NULL)« wurde erwartet, »resolvconf« erhalten main: line 673: 43 Killed which resolvconf > /dev/null 2>&1 File resolv.conf was modified Container start in progress... sudo vzctl status xxxxxxxxx VEID xxxxxxxxx exist mounted running our sudo config: Defaults log_input Defaults !log_passwords Defaults log_subcmds Defaults log_server_cabundle = /xxxxxxxxx.crt Defaults log_server_peer_cert = /xxxxxxxxx.crt Defaults log_server_peer_key = /xxxxxxxxx.key Defaults log_servers="xxxxxxxxx:30344(tls) xxxxxxxxx:30344(tls)" Containers also cannot start in a root shell with "sudo -i". There are no problems directly as root. It seems that arguments are not being passed properly. Is this because of sudo? Or is this behavior expected? sudo version sudo-1.9.14-3.el7.x86_64
This was supposed to be fixed in sudo 1.9.14 but the logic was not correct. I have verified that it is fixed by https://www.sudo.ws/repos/sudo/rev/49df34bb0494
You can work around the problem by disabling "intercept_verify". For example: Defaults !intercept_verify
I have upgraded to sudo-1.9.14-4 and tried with that option "Defaults !intercept_verify". I don't see the errors about arguments anymore. So everything looked good first, but the containers still have no working network after start. I have tried to start the containers within "sudo -i" with the same result. No errors, but containers are not working properly. When I enter the container in the "sudo -i" shell I get errors: broken interpreter. But I can enter the same running instance of the container as root without that error. Network is still not working there, but I think that is because the start scripts are still failed. sudo -i vzctl enter xxxxxxxxx entered into CT xxxxxxxxx -bash: /usr/bin/locale-check: No such file or directory -bash: /bin/lesspipe: /bin/sh: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden [root@xxxxxxxxx ~]# vzctl enter xxxxxxxxx entered into CT xxxxxxxxx
Newer versions of sudo will use ptrace(2) to track sub-commands on Linux. This usually means that the command being run by sudo cannot use ptrace(2) to trace its own child processes. For example, "sudo strace id" will fail because of this. It is possible that what runs your containers is trying to use ptrace(2) and failing. You could try switching to the "dso" method of sub-command tracing and see if that makes a difference. Defaults intercept_type=dso This has its own potential issues, though. It may be simplest to just skip sub-command logging for vzctl and potentially other container-related commands. For example: Cmnd_Alias VZ_CMDS = /usr/bin/vzctl Defaults!VZ_CMDS !log_subcmds
We have tried "Defaults intercept_type=dso" but with that container startig failed because of permission problems. sudo vzctl restart xxxxxxxxx Restart the Container [...] Starting Container ... Mount image: /xxxxxxxxx/root.hdd Container is mounted Setting permissions for image=/xxxxxxxxx/root.hdd Os release: 4.15.0 Turn userquota on vzctl: connect: Network is unreachable Failed to exec quotaon: Permission denied quotaon exited with error 42 Unmount image: /xxxxxxxxx/root.hdd (190) Container is unmounted Failed to start the Container Disable subshell logging for "/usr/sbin/vzctl seem to work. Then we can start containers with "sudo vzctl start CID" and then everything seems to work. --- Except starting containers from within "sudo -i" or "sudo -s" shell. We can start containers using sudo -i, but the network still doesn't work, because some commands inside the container are not working that way. I did some experimenting: For example: within sudo -i: ip a -bash: /bin/ip: Datei oder Verzeichnis nicht gefunden /bin/ip a -bash: /bin/ip: Datei oder Verzeichnis nicht gefunden ls -l /bin/ip -rwxr-xr-x 1 root root 558200 Jan 26 2021 /bin/ip* which ip /bin/ip ls -l /sbin/ip lrwxrwxrwx 1 root root 7 Jan 26 2021 /sbin/ip -> /bin/ip* /sbin/ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo [...] I can run ip via the link /sbin/ip but not /bin/ip direct. ss is not working at all, because there is no symlink in /sbin. But after creating a symlink "/sbin/ss -> /bin/ss" I can run ss via the symlink. ls -l /bin/ss -rwxr-xr-x 1 root root 139904 Jan 26 2021 /bin/ss ls -l /sbin/ss ls: Zugriff auf '/sbin/ss' nicht möglich: Datei oder Verzeichnis nicht gefunden ln -s /bin/ss /sbin/ss ls -l /sbin/ss lrwxrwxrwx 1 root root 7 Sep 20 11:56 /sbin/ss -> /bin/ss /sbin/ss Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port u_str ESTAB 0 0 * 51016824 * 51016823 * 51016811 [...] This is not happening on other commands in /bin or /usr/bin. And not on command in /sbin or /usr/sbin which netstat /bin/netstat netstat Aktive Internetverbindungen (ohne Server) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 xxxxxxxxxx:ssh xxxxxxxxxx:39824 VERBUNDEN Aktive Sockets in der UNIX-Domäne (ohne Server) Proto RefCnt Flags Type State I-Node Pfad unix 2 [ ] DGRAM 50918173 /var/spool/postfix/dev/log [...] which ifconfig /sbin/ifconfig ifconfig lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 [...] All those commands are working without problems after entering the container with "sudo vzctl enter CID" or via ssh-login to the container. echo $PATH /usr/local/sbin:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin: id uid=0(root) gid=0(root) Gruppen=0(root) The Container OS here was an ubuntu 18.04.6 --- Defaults log_input Defaults !log_passwords Defaults log_subcmds Defaults log_server_cabundle = xxxxxxxxx Defaults log_server_peer_cert = /xxxxxxxxx Defaults log_server_peer_key = xxxxxxxxx Defaults !intercept_verify # sudo Logserver Defaults log_servers="xxxxxxxxx:30344(tls) xxxxxxxxx:30344(tls)" Cmnd_Alias VZ_CMDS = /usr/sbin/vzctl Defaults!VZ_CMDS !log_subcmds