pkg/44233: don't set setuid-bit when installing as unprivileged user

[joern.clausen%uni-bielefeld.de@localhost]

>Number:         44233
>Category:       pkg
>Synopsis:       don't set setuid-bit when installing as unprivileged user
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 15 10:50:00 +0000 2010
>Originator:     Jörn Clausen
>Release:        
>Organization:
University of Bielefeld
>Environment:
>Description:
Some packages install binaries with the setuid-bit set. The assumption is 
probably, that root will install them. When doing an unprivileged install, 
these binaries are still installed setuid, but are owned by the unprivileged 
user:

$ find /usr/pkgsrc/current/libexec/ -perm -4000 | xargs ls -l
-r-s--x--x   1 pkgsrc   software  261636 Jun 16  2009 
/usr/pkgsrc/current/libexec/dbus-daemon-launch-helper
-r-sr-xr--   1 pkgsrc   software    8816 Jun 17  2009 
/usr/pkgsrc/current/libexec/polkit-grant-helper-pam
-r-sr-xr-x   1 pkgsrc   software    7416 Jun 17  2009 
/usr/pkgsrc/current/libexec/polkit-resolve-exe-helper
-r-sr-xr-x   1 pkgsrc   software   17752 Jun 17  2009 
/usr/pkgsrc/current/libexec/polkit-set-default-helper
-rws--x--x   1 pkgsrc   software  163236 Dec 10 13:39 
/usr/pkgsrc/current/libexec/ssh-keysign

I think in the case of an unprivileged install, the s-bit should not be set at 
all. In most environments, a mechanism to suppress the s-bit (e.g. mount 
options) will be employed anyways. But in case such a mechanism is not used, 
executing the binary as the real user instead of the unprivileged pkgsrc 
installer is probably the better solution.
>How-To-Repeat:

>Fix: