Re: Where to report: root fails to edit other users file in sticky bit directory
Am 08.12.2020 um 16:15 schrieb Greg Wooledge:
It *has* to be related to the kernel. Where else would the permissions
(capabilities) be applied?
That is exactly what I am wondering about. Those are pretty minimal
Debian install, no SELinux and no AppArmor actively installed, only what
is pulled in by core system requirements:
-------
root@VM-Bullseye:~# echo $(apt-mark showmanual)
apt bash-completion bzip2 ca-certificates cron curl dropbear gnupg
grub-pc haveged htop ifupdown iputils-ping kmod
linux-image-4.19.0-13-amd64 nano p7zip parted procps psmisc sudo
systemd-sysv systemd-timesyncd tiny-initramfs tzdata udev unzip vmtouch
wget whiptail
-------
But there during boot, AppArmor is sort of loaded:
-------
[ 1.051669] AppArmor: AppArmor initialized
[ 1.328558] AppArmor: AppArmor Filesystem Enabled
[ 1.782311] AppArmor: AppArmor sha1 policy hashing enabled
[ 2.753821] systemd[1]: systemd 247.1-3 running in system mode. (+PAM
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD
+IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
-------
libapparmor1 is pulled in by systemd. There was an update today from +b1
to +b2 version, but that did not make a difference.
But you didn't try it with buster's kernel yet?
I tried now the current Bullseye kernel, current Buster backports kernel
and current Buster kernel, it is definitely not kernel-related.
For that matter, how did you run this shell process? I see "VM" in
your shell prompt, so I'm guessing it's something far more complex
than "I booted my bullseye system, and logged in on the console as root".
It is exactly that simple and can be replicated on all sort of machines
(Raspberry Pi, VirtualBox VM, VMware and x86_64 notebook). The VM is
just most simple to test with.
Is there any possibility that the way you invoked your shell process
is messing with the capabilities(7) in such a way that you lost (or
never got) CAP_FOWNER?
-------
root@VM-Bullseye:~# capsh --print
Current: =ep
Bounding set
=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Current IAB:
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)
-------
cap_fowner is listed.
If it's not that, then someone's going to have to try to reproduce your
results, which would mean running a post-stable kernel, which means
"not me".
Jep, based on the way the list mail address was shown on the Debian bug
report page, I was actually hoping to reach official maintainers, but
this seems to be more an end-user support list?
(Also... "their current stable Linux 5.4" -- ???? Is this even DEBIAN?!
If this is a Raspbian or something, you're posting on the wrong mailing
list.)
Raspberry Pi is an ARM SoC, and as such, best featured by the official
kernel provided by the manufacturer: https://github.com/raspberrypi/linux
I'm running official Debian userland packages but with this
kernel/bootloader/firmware provided by their repository:
http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/
But it is irrelevant in this regards but only shows clearer the the
Linux version, hardware and CPU architecture doesn't play a role. I'm
guessing actually that it is something with systemd and/or AppArmor.
I'll try to switch to SysV init and purge the AppArmor library completely.
Best regards,
Micha
Reply to: