Wireshark-bugs: [Wireshark-bugs] [Bug 10247] Configure --enable-setcap-install does not set capa
Comment # 14
on bug 10247
from Guy Harris
(In reply to comment #13)
> My only thought would be: what if it's not a human doing "make install"?
>
> E.g., when building the RPM (or, presumably, the .deb) there's a tool
> running "make install" (into a temporary location).
>
> At least with the RPM there's really no point in using
> "--enable-setcap-install" (because the spec file controls the dumpcap
> permissions) but it doesn't mean somebody might not change the configure
> line within the spec file.
I guess my thought is that running configure with --enable-set*-install or
--with-dumpcap-group constitutes a demand that the installation of dumpcap set
its {owner ID+set-UID, capabilities, group ID+set-GID}, and if whoever caused
configure to be run with those options doesn't get what they want, they need to
arrange, somehow, that they can get what they want.
I.e., the non-human doing "make install" is, ultimately, doing the bidding of
some human or humans, and those humans need to do whatever is necessary to make
things work, even if that means *not* running the configure script with the
options in question, or having the non-human run as root, or being prepared to
be an sudoer and type their password while building the RPM or whatever.
> (Of course my other thought is: I thought sudo was declared a bad idea--and
> dead--like 20 years ago. But it seems to be used more and more in certain
> circles.)
Well, the first bits of what I found in a quick "sudo considered harmful"
search seem to be that sudo as a way for administrators to run the occasional
command as root is better than just running from a root shell, but that letting
the owner of a single-user machine use it to solve problems could be risky if
said owner isn't sufficiently knowledgable - "if something isn't happening the
way you want, put sudo in front":
https://gitorious.org/bkuhn/website/commit/4d81fda20f2b8aa522ef03539c3e24ac36a69f68
And, of course, sudo is software and is thus potentially buggy:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0034
You are receiving this mail because:
- You are watching all bug changes.
