Hi,
On Sun, Mar 13, 2011 at 08:37:53PM +0000, Ben Hutchings wrote:
> On Sun, 2011-03-13 at 20:56 +0100, Sebastian Harl wrote:
> > the new upstream version of one of my packages tries to set the
> > CAP_NET_RAW (permission to use RAW and PACKET sockets) file capability
> > during "make install" (using setcap(8)). (The affected tool sends ICMP
> > ECHO_REQUESTS ("pings"), thus needs to open a RAW socket. Imho, setting
> > the file capability is a nicer approach than setting the setuid bit.)
>
> This might be a little premature, as the version of 'ls' in unstable
> doesn't yet indicate files with setcap flags.
Good point.
> Also, what if the program is installed on a filesystem that doesn't
> support setcap?
Falling back to setuid (as mentioned below) would be a valid option imho
(also, that's the approach currently used).
> > Now, the question is: is it allowed to ship files having special
> > capabilities set. I couldn't find anything neither in the policy nor in
> > the devref. If the answer to that is "yes", how should the package
> > handle that? Using setcap(8) requires root privileges, so it cannot be
> > used in debian/rules.
>
> So do many things involving in building a package, which is why we have
> fakeroot. But more importantly:
>
> - fakeroot doesn't yet wrap capset(2)
> - tar (which is used by dpkg) doesn't save or restore setcap flags
Good points as well :-)
> > Would it be fine to do that in postinst?
>
> It must be done in postinst, and you may need to fall back to setuid if
> the filesystem does not support setcap.
Do you know of a way to find out if the filesystem supports setcap
(other than trying out ;-))?
Thanks for your feedback!
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
Attachment:
signature.asc
Description: Digital signature