[PATCH 0/4] import libcap from packages feed

Rosen Penev rosenp at gmail.com
Fri Mar 12 20:22:31 GMT 2021


On Fri, Mar 12, 2021 at 2:10 AM Stijn Tintel <stijn at linux-ipv6.be> wrote:
>
> On 12/03/2021 10:50, Petr Štetiar wrote:
> > Stijn Tintel <stijn at linux-ipv6.be> [2021-03-12 01:25:24]:
> >
> > Hi,
> >
> >> Having libcap in OpenWrt base allows us to enable libcap support in
> >> other packages in base.
> > there is same functionality available through procd already so essentialy
> > you're throwing away that effort, increasing flash space usage etc.
>
> Is that documented somewhere? Did you test that lldpd even starts when
> limiting it like that? I have had issues when I tried to limit the
> capabilities of infnoised [1] in the systemd unit file; it simply
> wouldn't start.
>
> The flash space usage is a moot point, we no longer care about 4MB
> devices, and libcap is only 12kb.  We can offset that by building lldpd
> with LTO.
>
> >
> >> In lldpd, this would allow the monitor process to drop its privileges
> >> instead of running as root, improving security. It will also allow us to
> >> drop our patch to disable libcap.
> > I assume, that you can do it even better with procd's seccomp/jails and
> > likely confine the master process as well.
>
> The non-monitor process already runs as the lldp user without libcap.
>
> Processes with libcap disabled:
>
>   1642 root      4360 S    /usr/sbin/lldpd -d -c -f -s -e -M 4 -x -X
> /var/run/agentx.sock
>   1693 lldp      4804 S    /usr/sbin/lldpd -d -c -f -s -e -M 4 -x -X
> /var/run/agentx.sock
>
> With libcap enabled:
>
>   1804 lldp      1216 S    /usr/sbin/lldpd -d -c -f -s -e -M 4
>   1886 lldp      1232 S    /usr/sbin/lldpd -d -c -f -s -e -M 4
>
> >
> >> I suspect some people might counter this by saying lldpd belongs in the
> >> packages feed;
> > IMO it belongs to packages feed, because currently it's optional package.  In
> > other words, it's not included in any of the images by default.
>
> See Bjorn's reply. It's required to properly support 802.3af/at/bt (PoE).
>
> Also, I don't agree that any optional package should be moved to the
> packages feed. The packages feed is a mess, often PR's are accepted
> without maintainer approval, sometimes even after explicit NACK by the
> maintainer or others. For this reason, I'm seriously considering
> removing myself as maintainer from any packages I maintain there.
No idea about explicit NACK. I merge mostly complete PRs to avoid the
situation in base where hundreds of good PRs pile up only because
there is no one to review.
>
> >
> >> I strongly disagree as imo LLDP is an essential service for any network
> >> device, and especially switches. Even the cheapest managed switches support
> >> LLDP for more than 5 years already.
> > If it's that essential, why it's not enabled and shipped by default? I assume
> > it's because some folks would complain, that LLDP is use case specific, not
> > everybody would like to have another network exposed service running by
> > default, not everybody needs LLDP by default in RX/TX mode as TX mode might be
> > enough etc.
> We're considering enabling it on realtek by default.
> >
> > Cheers,
> >
> > Petr
>
> Stijn
>
> [1] https://github.com/13-37-org/infnoise
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list