Re: Apache->CGI script, NOPASSWD is set, but sudo requires auth

  Hello.
  
On Tue, Mar 10, 2026 at 12:02:01PM +0300, Evgeniy Berdnikov wrote:
> On Mon, Mar 09, 2026 at 08:18:28PM -0600, Todd C. Miller wrote:
> > On Mon, 09 Mar 2026 13:03:24 +0300, Evgeniy Berdnikov wrote:
> > That sounds like a different issue.  Is your cgi script executing
> > in a chroot jail by any chance?
> 
>  Problem is reproduced inside VM, as well as inside LXC container.
>  
>  I tried LXC to run container on fresh Debian (where problem is reproduced)
>  and on old Ubuntu (where problem is not reproduced), result is the same.
>  I think it excludes dependence on systemd and cgroups (on Linux).

 This issue was resolved. I run strace on Apache processes and found

217454 openat(AT_FDCWD, "/etc/sudoers", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission denied)

 while /etc/sudoers should be read from suid program. This file appears to be
 unreadable for CGI script. Setting world read permissions for it
 does not help.

 After some search around (apparmor, selinux, etc) I found that reason was
 in systemd unit configuration for Apache in fresh Debian systems:

 InaccessiblePaths=-/etc/sudoers
 InaccessiblePaths=-/etc/sudoers.d

 Removing those lines solves the problem.

 I think this "security improvement" is questionable. In Debian package
 /etc/sudoers is not world-readable, so it can't be read from CGI script
 with uid=33(www-data)/gid=33(www-data). However, /etc/sudoers.d is packaged
 as world-readable, so attacker from CGI script would read files from
 /etc/sudoers.d if they are not properly protected:

-r--r----- 1 root root 1881 Feb 10 23:29 /etc/sudoers
drwxr-xr-x 2 root root   22 Mar 10 11:07 /etc/sudoers.d

 I think right solution should be default drwxr-x--- mode (550) for
 /etc/sudoers.d, and mentioned restrictions in Apache unit file
 should be removed. Any objections?
-- 
 Eugene Berdnikov
____________________________________________________________
sudo-users mailing list <[email protected]>
For list information, options, or to unsubscribe, visit:
https://www.sudo.ws/mailman/listinfo/sudo-users