Re: horse carcas flogging (was: traceroute in /usr/bin, not /usr/sbin)
On Sun, 17 Jun 2001, Adam McKenna wrote:
> On Mon, Jun 18, 2001 at 01:21:47AM -0500, Steve Langasek wrote:
> > > Yes, but in this case, it's impossible because traceroute needs to be suid.
> > > It needs to set certain socket parameters that can only be set by root.
> > Precisely... if traceroute is a tool that /needs/ to be set suid root because
> > there are people using it who don't have root privileges, isn't that a pretty
> > good indicator that traceroute is not exclusively a tool for admins?
> Did you actually read the rest of my message, or did you ignore the second
> part that you also conveniently removed (I assume in an attempt to make your
> argument stronger)?
I'm sorry, I made the mistake of assuming it was self-evident that any tool
which finds its usefulness limited when it's no longer accessible to users who
don't have root access is not an admin tool. If there are users availing
themselves of traceroute to whom the system administrator would not be willing
to give administrative access (with or without the 'adm' group, which I've
never had to make use of on any of my systems), that represents a rather
strong argument that it's not exclusively a tool for admins, IMO.
> Traceroute is an admin tool, but not all admins have root, which is WHY I
> suggested the default ownership/permissions be changed.
Doesn't it seem a little odd to be changing the permissions on a program to
disallow user access, for no other reason than to further your claim that
traceroute is an admin tool? Debian is built on principles of openness, yet
here we are discussing locking down access to a very useful tool -- not
because it's a threat to system security, but because it's been dubbed an
'admin tool', and the proponents of this point of view would rather shoot
their users in the foot than consider arguments to the contrary. There simply
isn't any justification for the assertion that traceroute is a 'system
administration' tool.
But again, I'm assuming that the definition of 'system administrator'
precludes users who don't have root access, and that a tool which is
legitimately used by non-administrators is not a 'system administration tool'
as defined by the FHS. Since neither of these assumptions seems to be
universally held, I invite you to provide another definition for 'system
administrator' and 'system administration tool' that *by itself*, and *without
referencing traceroute by name*, justifies the placement of traceroute in
/usr/sbin. I've seen a lot of insistence that traceroute is an admin tool,
but nothing but fiat to back up that claim. There certainly hasn't been
anything even remotely close to an effort to provide objective criteria for
determining the status of a program, to explain why traceroute belongs in
/usr/sbin but, e.g., lpq belongs in /usr/bin. And this support of completely
arbitrary and inconsistent categorization offends *my* sense of esthetics.
I agree with Rene; it's one thing to admit that Debian cannot be fully
FHS-compliant for whatever reasons, and quite another to ignore glaring
inconsistencies in our implementation thereof.
Steve Langasek
postmodern programmer
Reply to: