Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Nico Kadel-Garcia]

Reading from the spec:

> The solution is to permit symlinks to only be followed when outside a sticky world-writable directory, or when the uid of the symlink and follower match, or when the directory owner matches the symlink's owner.

It was a bit unclear to me the first time I read it: I thought it was
"and", not "or". So this is not as restrictive as I thought, and I'll
withdraw my conerrn about this breaking linking /sbin/* or /us/sbin/*
programs to $HOME//bin/.

On Sun, Mar 24, 2013 at 9:19 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>
>
> Am 24.03.2013 04:08, schrieb Kevin Kofler:
>> Miloslav Trmač wrote:
>>> BTW determining this accurately should be fairly doable[1].  Just look
>>> for symlink() and link() calls (and recursively through wrapper APIs /
>>> language bindings).  These syscalls are fairly rare.
>>
>> That checks for PROGRAMS which run into this. It catches neither admin's
>> custom scripts nor ln commands run directly by the users. Who knows on how
>> many machines manually created symlinks point to inodes owned by different
>> users?
>
> maybe you guys should read what the protection does
> how many directories except /tmp are world-writeable and have STICKY bit?
>
> fs.protected_symlink
> symlinks to only be followed when outside a sticky world-writable directory
>
> fs.protected_hardlinks
> blocks hardlinks to other people's WORLD-READABLE files if you can't write to them
>
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel