Re: problems with latest x version in incoming
Joey Hess wrote:
>Branden Robinson wrote:
>> Well, I was just following the example set in sendmail.
>>
># manage setuid X binary
>> if [ -x /usr/sbin/suidregister ]; then
>> suidregister -s xserver-common /usr/X11R6/bin/X root root 4755
>> else
>> chmod 4755 /usr/X11R6/bin/X
>> fi
>
>The above is fine, it is how suidmanager's README.Debian says to do it.
>I don't understand why the docs say to put in the chmod too. I guess so long
>as you have the chmod in there, it doesn't matter if you make the .deb file
>actually have the suid bit set in it or not - I tend to go ahead and put the
>suid bit in the deb file because then lintian can check on it, and because
>it's clearer if someone looks at the .deb that it does contain suid
>componentd.
I did the same as Branden, but for xvt: made the binary mode 0755 in
the package, and made it setuid using suidmanager if available, or use
chmod if not. However, I did this for my own reason, not because I read
it in a README...
The reason was that, when the package is upgraded, there is a window of
time (sometimes quite long) between the unpacking phase and configuration.
If the sysadmin wants xvt not to be setuid, we're doing him a diservice by
allowing it to be setuid for an indefinite period before configuration.
By putting a non-setuid binary in the package, xvt will never be setuid
if the sysadmin has specified to suidmanager that it should not be.
My guess is that whoever wrote that README was thinking the same way.
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Reply to: