[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1033477: linux: symlink in sticky directory not owned 0:0 behaves weirdly (EACCES if mode 1777, okay if 1755, &c.)



Control: reassign -1 manpages 6.03-1

Hi!

On Sat, Mar 25, 2023 at 09:13:14PM +0100, Salvatore Bonaccorso wrote:
> Since several releses Debian sets fs.protected_symlinks=1 by default.
> 
> In the above case we have a sticky world-writable directory and the
> directory owner does not match the symlink owner and the follower's
> uid does not match the symlink's uid.

Yep, with some kernel tracing I managed to find this comes from
may_follow_link() and goes away with /proc/sys/fs/protected_symlinks=0,
thanks for confirming that's as-expected and as-appears.

That said, the requirements are esoteric, and symlink(7) says 
  The owner and group of an existing symbolic link can be changed using
  lchown(2).  The only time that the ownership of a symbolic link
  matters is when  the  link is being removed or renamed in a directory
  that has the sticky bit set (see stat(2)).
which initially put me onto "this is a kernel bug" rather than
"this is a security tunable", I'll write a blurb there.

Best,
наб

Attachment: signature.asc
Description: PGP signature


Reply to: