As a user which tries to keep a keen security combined with an updated system I have as a part of the security removed suided binaries which I don't find the use for in my system to decrease the risk of local exploitation of binaries by users. I have also made a script to auto emerge sync and emerge -U world every night at 4am to always get the latest versions of packages installed. When portage updates a package it compiles it in a sandbox environment, overwrite exising files and remove "left over" files from the older package version. This works good except for suid bits which I have removed of binaries, that are reset to package defaults. I talked about it in #gentoo-portage and recived positive response which encouraged me to post it here. One comment I got was "[14:55:12] <jstubbs> hardened folk would probably be agreeable to the idea, too." Reproducible: Always Steps to Reproduce: 1. Emerge package 2. Remove suid bit 3. Reemerge package Actual Results: Suid bit is reset to binaries after manually removing them. Expected Results: Keep the existing suid bit status on files it upgrade, or atleast have the option for enabling this check (as it might slow the emerge down with a few seconds) I didn't really know if I should post it as a "Normal" bug or a "Major". Depends on how you look at suid bits as a security of your system, but here it goes as normal, as that is what I classify it as.
I think we should not do it automatically. What do you and portage guys think about NOSETUID="/usr/bin/foo /usr/bin/bar" NOSETUIDODIR="/usr/bin" etc in make.conf.
This was available in .50 and above via the suidctl feature.
