Configure --enable-setcap-install does not set capabilities of dumpcap on install if installation isn't done as root
This issue was migrated from bug 10247 in our old bug tracker.
Original bug information:
Reporter: mal…@gma…
Status: RESOLVED FIXED
Product: Wireshark
Component: Build process
OS: Linux
Platform: All
Version: 1.10.8
Activity
Build Information: wireshark 1.10.8 (Git Rev Unknown from unknown)
Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.13.1, with Pango 1.36.3, with GLib 2.40.0, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux), with libnl 1, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2, without Python, with GnuTLS 2.12.23, with Gcrypt 1.5.3, with MIT Kerberos, without GeoIP, with PortAudio <= V18, without AirPcap.
Running on Linux 3.15.0-031500-generic, with locale en_US.UTF-8, with libpcap version 1.5.3, with libz 1.2.8, GnuTLS 2.12.23, Gcrypt 1.5.3. Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz
Built using gcc 4.8.2.
After launching $./configure --prefix=/home/user/bin/wireshark-1.10.8 --enable-setcap-install --with-ssl && make install on Ubuntu 14.04 I get dumpcap without any capabilities : $ ls -l ~/bin/wireshark-1.10.8/bin -rwxr-xr-x 1 user user 145K lip 2 03:08 capinfos -rwxr-xr-x 1 user user 41K lip 2 03:08 dftest -rwxr-x--x 1 user user 327K lip 2 03:08 dumpcap -rwxr-xr-x 1 user user 177K lip 2 03:08 editcap -rwxr-xr-x 1 user user 59K lip 2 03:08 mergecap -rwxr-xr-x 1 user user 34K lip 2 03:08 randpkt -rwxr-xr-x 1 user user 367K lip 2 03:08 rawshark -rwxr-xr-x 1 user user 30K lip 2 03:08 reordercap -rwxr-xr-x 1 user user 119K lip 2 03:08 text2pcap -rwxr-xr-x 1 user user 1.3M lip 2 03:08 tshark -rwxr-xr-x 1 user user 8.9M lip 2 03:08 wireshark $ getcap dumpcap $ when I set it manually it works fine $sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' dumpcap after that I can run wireshark which will the the interfaces.added build oslinux version1.10 labels
-
OK, that makes sense *but* after running make install with sudo I get all the binaries, libraries, directories, etc. that are owned by root, e.g.: ~/bin/wireshark-1.10.8$ ls -l total 12 drwxr-xr-x 2 root root 4096 lip 2 21:53 bin drwxr-xr-x 3 root root 4096 lip 2 21:53 lib drwxr-xr-x 4 root root 4096 lip 2 21:53 share ~/bin/wireshark-1.10.8$ ls -l bin/ total 11748 -rwxr-xr-x 1 root root 147783 lip 2 21:53 capinfos -rwxr-xr-x 1 root root 41586 lip 2 21:53 dftest -rwxr-x--x 1 root root 334377 lip 2 21:53 dumpcap -rwxr-xr-x 1 root root 180866 lip 2 21:53 editcap -rwxr-xr-x 1 root root 60176 lip 2 21:53 mergecap -rwxr-xr-x 1 root root 34704 lip 2 21:53 randpkt -rwxr-xr-x 1 root root 375401 lip 2 21:53 rawshark -rwxr-xr-x 1 root root 30561 lip 2 21:53 reordercap -rwxr-xr-x 1 root root 121280 lip 2 21:53 text2pcap -rwxr-xr-x 1 root root 1359239 lip 2 21:53 tshark -rwxr-xr-x 1 root root 9319337 lip 2 21:53 wireshark -
It worked on my Fedora 16 and Ubuntu 12.04 (virtual) machines when I did `sudo make install` after configuring with `--enable-setcap-install`, with the default installation prefix, i.e. /usr/local. I then configured it, on the Ubuntu machine, to be installed under my home directory; `make install` *didn't* fail, but it also didn't set the capabilities. The installation reported /sbin/setcap cap_net_raw,cap_net_admin+ep /home/gharris/bin/dumpcap unable to set CAP_SETFCAP effective capability: Operation not permitted make[4]: [install-exec-hook] Error 1 (ignored) Makefile.am precedes the "set the group of dumpcap", "set the capabilities of dumpcap", and "make set-UID" commands in the install-exec-hook target with "-", so that errors are ignored. Unless somebody can come up with a good reason to ignore errors in those commands, I'd vote for removing the "-"es, so that a failure stops the installation and thus makes the user more aware of the failure. -
(In reply to comment #3) > OK, that makes sense *but* after running make install with sudo I get all > the binaries, libraries, directories, etc. that are owned by root, e.g.: Sadly, setting capabilities apparently requires root privileges (which should not be surprising), so at least some of the installation commands have to be run as root. The alternatives, for those who want dumpcap to have extra privileges but don't want all the binaries owned by root, are thus: run the installation as root, and change the ownership afterwards; run the installation as yourself, and add the privileges afterwards; have the Makefile run those commands with "sudo", at least if the configure script found sudo. -
(In reply to comment #6)
> @Guy, well the best option would be the 3rd one - so that Makefile would
> check if there's sudo on the system and if there is then ask for password
> (or check if the privileges have been given - sudo password timeout on e.g.
> Ubuntu).What happens if the user is not a sudoer?
-
(In reply to comment #4)
> Unless somebody can come up with a good reason to ignore errors in those
> commands, I'd vote for removing the "-"es, so that a failure stops the
> installation and thus makes the user more aware of the failure.Done in change I34393bc2c9ea4dc59854a08524edb4f65e79730b.
Not fixed, yet, as we haven't yet decided whether to add sudo to the Makefile or not.
-
(In reply to comment #7)
> (In reply to comment #6)
> > @Guy, well the best option would be the 3rd one - so that Makefile would
> > check if there's sudo on the system and if there is then ask for password
> > (or check if the privileges have been given - sudo password timeout on e.g.
> > Ubuntu).
>
> What happens if the user is not a sudoer?Then sudo fails and they don't get to have what they want - which they won't be able to get no matter what, as the administrator of the machine has decided that they shouldn't have the privileges necessary to get what they want.
-
(In reply to comment #6) > @Guy, well the best option would be the 3rd one - so that Makefile would > check if there's sudo on the system and if there is then ask for password > (or check if the privileges have been given - sudo password timeout on e.g. > Ubuntu). The *configure script* would check for sudo, and set up the Makefile to use it fi present. The Makefile would, in that case, run the privilege-granding programs with sudo, and sudo would then ask for the password if it hasn't been given sufficiently recently. -
(In reply to comment #10) > (In reply to comment #6) > > @Guy, well the best option would be the 3rd one - so that Makefile would > > check if there's sudo on the system and if there is then ask for password > > (or check if the privileges have been given - sudo password timeout on e.g. > > Ubuntu). > > The *configure script* would check for sudo, and set up the Makefile to use > it fi present. > > The Makefile would, in that case, run the privilege-granding programs with > sudo, and sudo would then ask for the password if it hasn't been given > sufficiently recently. That's good solution but can this be done by you guys and more importantly - will it be done? -
(In reply to comment #11)
> That's good solution but can this be done by you guys and more importantly -
> will it be done?Can this be done? Yes.
Will this be done? Only if nobody comes up with significant problems with it. I'd like to allow at least a few days for others to comment on this.
-
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.
(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.)
-
(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 -
(In reply to comment #15) > (Gerrit, *PLEASE* stop thinking that, just because a commit message has the > string "bug XXXX" in it, the commit necessarily fixes bug XXXX. I *REALLY* > don't want to have to start referring to "bug ten thousand two hundred and > forty-seven".) May be use like OpenStack Closed-bug, Partial-Bug... ? (and change gerrit buildbot integration plugin...) https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references -
(In reply to comment #14) > (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. Agreed--I would just prefer it fail in a "nice" way. :-) E.g., rpmbuild hanging because it's waiting for you to type enter a password's probably not so great.