[sudo-users] Calling sudo from PHP script under Apache httpd

[Dima Goncharuck]

Hi Todd,

Thursday, February 11, 2021, 6:18:46 PM, Вы написали:

> On Thu, 11 Feb 2021 11:45:28 +0200, Dima Goncharuck wrote:

>> I have some problem with subj and I can't detect a source(s) of a problem(s).
>>
>>  So, I need to run some command by php script via Apache HTTPD.
>>  And it's not working at all. In httpd log file (/var/log/apache/error.log) I
>>  can see this:
>>  
>> sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted
>> sudo: unable to initialize policy plugin
>>
>> With turned on sudo debug I can see this (/var/log/sudo_debug.log):

> The debug information you want may be in the sudoers debug log.
> Try the following in your /etc/sudo.conf file.

> Debug sudoers.so /var/log/sudoers_debug all at debug
               ^^^ Thanks. My mistake. That is why in my case this log even wasn't present.
               
 Now it looks like this:
 
Feb 11 18:52:08 sudo[5079] -> sudoers_init @ ./sudoers.c:160
Feb 11 18:52:08 sudo[5079] -> sudoers_policy_deserialize_info @ ./policy.c:97
Feb 11 18:52:08 sudo[5079] settings: plugin_path=/usr/lib/sudo/sudoers.so
Feb 11 18:52:08 sudo[5079] settings: progname=sudo
Feb 11 18:52:08 sudo[5079] settings: network_addrs=192.168.255.4/255.255.255.240 192.168.88.166/255.255.255.0
Feb 11 18:52:08 sudo[5079] settings: plugin_dir=/usr/lib/sudo/
Feb 11 18:52:08 sudo[5079] settings: debug_flags=/var/log/sudo_plugin.log all at info,plugin at debug
Feb 11 18:52:08 sudo[5079] user_info: user=ubill
Feb 11 18:52:08 sudo[5079] user_info: pid=5079
Feb 11 18:52:08 sudo[5079] user_info: ppid=5078
Feb 11 18:52:08 sudo[5079] user_info: pgid=5048
Feb 11 18:52:08 sudo[5079] user_info: tcpgid=0
Feb 11 18:52:08 sudo[5079] user_info: sid=5048
Feb 11 18:52:08 sudo[5079] user_info: uid=10001
Feb 11 18:52:08 sudo[5079] user_info: euid=0
Feb 11 18:52:08 sudo[5079] user_info: gid=10001
Feb 11 18:52:08 sudo[5079] user_info: egid=10001
Feb 11 18:52:08 sudo[5079] user_info: groups=10001
Feb 11 18:52:08 sudo[5079] user_info: umask=00
Feb 11 18:52:08 sudo[5079] user_info: cwd=/var/www/ubill
Feb 11 18:52:08 sudo[5079] user_info: host=bl
Feb 11 18:52:08 sudo[5079] user_info: lines=24
Feb 11 18:52:08 sudo[5079] user_info: cols=80
Feb 11 18:52:08 sudo[5079] user_info: rlimit_as=infinity,infinity
Feb 11 18:52:08 sudo[5079] user_info: rlimit_core=0,infinity
Feb 11 18:52:08 sudo[5079] user_info: rlimit_cpu=infinity,infinity
Feb 11 18:52:08 sudo[5079] user_info: rlimit_data=infinity,infinity
Feb 11 18:52:08 sudo[5079] user_info: rlimit_fsize=infinity,infinity
Feb 11 18:52:08 sudo[5079] user_info: rlimit_locks=infinity,infinity
Feb 11 18:52:08 sudo[5079] user_info: rlimit_memlock=65536,65536
Feb 11 18:52:08 sudo[5079] user_info: rlimit_nofile=8192,8192
Feb 11 18:52:08 sudo[5079] user_info: rlimit_nproc=193154,193154
Feb 11 18:52:08 sudo[5079] user_info: rlimit_rss=infinity,infinity
Feb 11 18:52:08 sudo[5079] user_info: rlimit_stack=8388608,infinity
Feb 11 18:52:08 sudo[5079] <- sudoers_policy_deserialize_info @ ./policy.c:530 := 0
Feb 11 18:52:08 sudo[5079] -> init_vars @ ./sudoers.c:789
Feb 11 18:52:08 sudo[5079] sudoers_initlocale: user locale C, sudoers locale C
Feb 11 18:52:08 sudo[5079] set_perms: PERM_INITIAL: ruid: 10001, euid: 0, suid: 0, rgid: 10001, egid: 10001, sgid: 10001
Feb 11 18:52:08 sudo[5079] -> set_callbacks @ ./sudoers.c:1584
Feb 11 18:52:08 sudo[5079] <- set_callbacks @ ./sudoers.c:1635
Feb 11 18:52:08 sudo[5079] -> set_runaspw @ ./sudoers.c:1304
Feb 11 18:52:08 sudo[5079] <- set_runaspw @ ./sudoers.c:1327 := true
Feb 11 18:52:08 sudo[5079] <- init_vars @ ./sudoers.c:878 := true
Feb 11 18:52:08 sudo[5079] set_perms: PERM_ROOT: uid: [10001, 0, 0] -> [0, 0, 0]
Feb 11 18:52:08 sudo[5079] PERM_ROOT: setresuid(0, -1, -1): Operation not permitted @ set_perms() ./set_perms.c:361
Feb 11 18:52:08 sudo[5079] <- sudoers_init @ ./sudoers.c:193 := -1


> Perhaps PHP runs commands in a sandbox (using seccomp or something
> similar) that disables changing the uid?
I don't know :( Will check this.

> You should check the audit
> log (if it exists) to see if there is anything relevant in it.
  Auth log does not have any info about this events ( usually any sudo events are passed here )
  Audit log is not present.

> It is also possible that AppArmor is interfering with sudo.  You
> can run "aa-status" as root to see whether it is enabled (assuming
> it is even installed).  The audit log should also contain information
> about AppArmor if it is getting in the way.
  No, apparmor was removed imiddiately after 4.19 kernel was installed.

-- 
С уважением,
 Dima                            mailto:dgoncharuk at neocm.com