Re: The unanswered Question
Christoph Lameter quotes from the policy manual:
> Some setuid programs need to be restricted [...]
and
> Instead you should consider (for example) creating a group for people
> allowed to use the program(s) and making any setuid executables
> executable only by that group.
He then asks:
> Why were so many people opposed when I did these things in the past?
Those sections of the manual were written with programs in mind that
needed be setuid. They _do not discuss_ the issue of whether a binary
should be setuid at all; I naively believed that people would behave
sensibly and cautiously in this respect.
Packet sniffers and Debian packaging tools (to take your examples) do
_not_ need to be setuid. On many systems giving someone access to a
packet sniffer is practically the same as giving them root (because
they can sniff passwords), and giving someone setuid-root access to a
program that runs debian/rules is definitely the same as giving them
root.
These programs should be ordinary binaries, and if a sysadmin wants to
have a local policy that says users X and Y may do Z then sudo is the
right tool for the job, or they can write a wrapper and put it in
/usr/local. The setuid bit is _not_ appropriate here.
> dosemu and debmake both violate that section. Thus I should
> provide a group for both of them or do something else to avoid modifying
> permissions on files in order to accomplish functionality.
No, you should _not make them setuid_.
Ian.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: