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

[Nico Kadel-Garcia]

On Sat, Mar 23, 2013 at 11:08 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> 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?

For example, I've been known to link /sbin programs to $HOME/bin/. on
hosts I use and do not have root access on, so that "traceroute" iour
"chkconfig" or the "hardlink" program are always avaialble. The
decision to leave "/sbin" out of the default PATH except for root
users has created many interesting such situations. This is especially
true in environments where commercial or experimental versions of gcc
or Java are instlled in /usr/local/gcc or /usr/local/java or
/opt/[package] on some hosts and not others, and need to be activated
on a user-by-user basis.

>> [1] Well, "fairly doable" when compared to the /tmp-on-tmpfs, which is
>> "just impossible".  It's still man-weeks of work.  Pragmatically
>> speaking, "It did not break Ubuntu" is not a QA technique that makes
>> me happy, but might be good enough anyway.
>
> Well, /tmp-on-tmpfs is just broken, disabled on my machines and should be
> reverted in Fedora ASAP. It is not a good example to follow (and neither is
> UsrMove, whose consequences we're still suffering, see the recent thread
> about RPM dependencies on binaries).

Amen.