You are not logged in.
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 (2024-11-27 08:16:49)
Offline
“/etc/sudoers” permissions are “.r--r-----”. Note the dot in the begining. Can you check with the following line?
sudo ls --context /etc/sudoers
Sometimes I seem a bit harsh — don’t get offended too easily!
Online
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
Offline
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.
Sometimes I seem a bit harsh — don’t get offended too easily!
Online
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)
Offline
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)
Offline
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=
Offline
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.
Offline