[SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

Strykar · 2024-11-23 19:06:52

I'd like some help understanding a log that does not make sense, the sudoers file permission seems correct.
I noticed it as the only failure in my bootlog:

$ journalctl -b
Nov 23 22:04:55 t14s sudo[612]:     root : unable to open /etc/sudoers : Operation not permitted ; PWD=/ ; USER=root ;

But the permissions seem right, ran "visudo -c" to be sure:

$ ls -l /etc/sudoers
Permissions Size User Group Date Modified Name
.r--r-----  5.0k root root  23 Nov 21:24  /etc/sudoers

The install is a single LUKS root partition (TPM2 + TPM pin) with a swapfile:

$ lsblk -f

NAME        FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1                                                                                 
├─nvme0n1p1 vfat        FAT32       A5FA-9826                                           
└─nvme0n1p2 crypto_LUKS 2           8412004d-f64a-4ad3-a8fd-4f86df3aca43                
  └─root    ext4        1.0         15ac1ef5-636b-4340-933b-fac048951926  309.6G    29% /

$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   4G   0B   -2

The machine is a Thinkpad T14s notebook and the only other issue is that the display does not come back on after suspend, but hibernation works. My kernel options:

$ cat /proc/cmdline
rw resume=/dev/mapper/root resume_offset=4161536 fsck.mode=force fsck.repair=yes delayacct fbcon=font:TER16x32 i915.enable_gvt=1 i915.enable_guc=0 i915.force_probe=!9a49 xe.force_probe=9a49

The only other possible connection to this I found was in the shutdown log:

[     shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy
[     shutdown[1]: Unable to finalize remaining DM devices, ignoring.
[     reboot: restarting system

As /dev/mapper/root symlinks to /dev/dm-0 and the underlying partition is /dev/nvme0n1p2:

$ sudo ls -l  /dev/mapper/root
Permissions Size User Group Date Modified Name
lrwxrwxrwx     - root root  24 Nov 00:21  /dev/mapper/root -> ../dm-0

What is causing this, what am I missing?

Last edited by Strykar (Yesterday 08:16:49)

mpan · 2024-11-23 19:25:54

“/etc/sudoers” permissions are “.r--r-----”. Note the dot in the begining. Can you check with the following line?

sudo ls --context /etc/sudoers

Strykar · 2024-11-23 19:41:17

I run eza, I also included old ls output:

$ sudo ls --context /etc/sudoers
Permissions Size User Group Security Context Date Modified Name
.r--r-----  5.0k root root  ?                23 Nov 21:24   /etc/sudoers

$ sudo /usr/bin/ls --context /etc/sudoers
? /etc/sudoers

mpan · 2024-11-24 05:19:38

Are you using SELinux? Because it seems to be what prevents access to the file. The above output of `ls --context` didn’t provide anything useful, though.

I’m not myself experience in SELinux, so I can’t help much more than pointing to that direction. setfattr may be used to remove any extended attributes from a file. For SELinux context that would be:

setfattr -x security.selinux

But I suppose that will not work if SELinux is in force.

Strykar · 2024-11-24 09:32:07

I am not using SELinux:

~ sudo setfattr -x security.selinux /etc/sudoers
setfattr: /etc/sudoers: No such attribute

Here is the same log after booting with selinux=0 without using eza:

Nov 24 14:53:12 t14s systemd[1]: Finished Load Kernel Module loop.
Nov 24 14:53:12 t14s sudo[630]:     root : unable to open /etc/sudoers : Operation not permitted ; PWD=/ ; USER=root ;
Nov 24 14:53:12 t14s systemd[1]: Repartition Root Disk was skipped because no trigger condition checks were met.

~ sudo ls -l /etc/sudoers
-r--r----- 1 root root 5029 Nov 23 21:24 /etc/sudoers

I'm sorry, it seems eza displays the dot there and I will ask why upstream but it appears unrelated to the permission issue in the bootlog:
dmesg with selinux=0.

Last edited by Strykar (2024-11-24 13:05:28)

tekstryder · 2024-11-24 13:04:30

Strykar wrote:

eza displays the dot there

$ ls -l /etc | grep sudoers
-r--r----- 1 root   root     4883 Oct 22 07:58 sudoers
drwxr-x--- 2 root   root     4096 Jan 26  2021 sudoers.d

$ eza -l /etc | grep sudoers
.r--r----- 4.9k root   22 Oct 06:58 sudoers
drwxr-x---    - root   26 Jan  2021 sudoers.d

I'm speculating they chose a leading dot rather than a dash when distinguishing file types because it's clearer than the leading dash, which could be confused with an unset permission.

Last edited by tekstryder (2024-11-24 13:07:37)

Strykar · 2024-11-26 20:29:46

The issue was a bash script I ran to enable the LTE / WWAN connection that had sudo in it.
I realized it seeing the same log when I tried to restart ModemManager.service that ran the bash script as an ExecStartPost=

seth · Yesterday 07:15:36

https://wiki.archlinux.org/title/Securi … n_attempts

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2024-11-23 19:06:52

[SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

#2 2024-11-23 19:25:54

Re: [SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

#3 2024-11-23 19:41:17

Re: [SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

#4 2024-11-24 05:19:38

Re: [SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

#5 2024-11-24 09:32:07

Re: [SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

#6 2024-11-24 13:04:30

Re: [SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

#7 2024-11-26 20:29:46

Re: [SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

#8 Yesterday 07:15:36

Re: [SOLVED] sudo: root: unable to open /etc/sudoers: Operation not permit

Board footer