Comment # 17
on bug 10247
from Jeff Morriss
(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.
You are receiving this mail because:
- You are watching all bug changes.