Bug 40369 – Portage dosen't keep suid bits as they were on package upgrade

• Product: Portage Development
• Status: RESOLVED FIXED

[Description mhakali 2004-02-04 06:10:48 UTC]

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.

[Comment 1 Masatomo Nakano (RETIRED) 2004-02-10 17:31:05 UTC]

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.

[Comment 2 Brian Harring (RETIRED) 2004-11-08 00:44:48 UTC]

This was available in .50 and above via the suidctl feature.