Your message dated Sat, 30 Dec 2023 03:30:49 +0100 with message-id <ofqsqw66szkjlx3uhqw5o3y34du3ucadecc6w4sbgbqxmzo...@tarta.nabijaczleweli.xyz> and subject line Done: Bug#1033477: linux: symlink in sticky directory not owned 0:0 behaves weirdly (EACCES if mode 1777, okay if 1755, &c.) has caused the Debian Bug report #1033477, regarding linux: symlink in sticky directory not owned 0:0 behaves weirdly (EACCES if mode 1777, okay if 1755, &c.) to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1033477: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033477 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Source: linux Version: 6.1.20-1 Severity: normal Dear Maintainer, Here's a session that demonstrates the issue: -- >8 -- /srv# echo /srv/f > f /srv# mkdir -m 1777 1777 /srv# ln -s /srv/f 1777/ /srv# chown _apt 1777/ /srv$ cat 1777/f cat: 1777/f: Permission denied /srv$ cat f /srv/f -- >8 -- Or, in short: -- >8 -- $ find /srv/ -exec ls -ld {} + drwxr-xr-x 3 root root 4096 Mar 25 17:34 /srv/ drwxrwxrwt 2 _apt root 4096 Mar 25 17:34 /srv/1777 lrwxrwxrwx 1 root root 6 Mar 25 17:34 /srv/1777/f -> /srv/f -rw-r--r-- 1 root root 7 Mar 25 17:34 /srv/f -- >8 -- If you don't chown (leave it owned 0:0), the cat succeeds. If you make it 1755 instead of 1777, the cat succeeds as well! This is obviously insane, but I'm assuming no-one noticed because no-one uses sticky directories not owned 0:0. If you additionally mkdir 1777/dir and make an identical symlink there, the cat also succeeds. Naturally, it should succeed in every scenario. Best, наб -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: amd64, i386 Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---Version: 6.05.01-1 As Helge said, this is fixed in 6.05.01-1, now in sid ‒ $ man 7 symlink | grep -m1 -A2 'ownership of' The owner and group of an existing symbolic link can be changed using lchown(2). The ownership of a symbolic link matters when the link is being removed or renamed in a directory that has the sticky bit set (see in‐ ode(7)), and when the fs.protected_symlinks sysctl is set (see proc(5)). ‒ and this was unclosed. Best, наб
Description: PGP signature
--- End Message ---
