Date: Wed, 14 Nov 2012 13:58:25 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Markus Gebert <markus.gebert@hostpoint.ch>, rwatson@freebsd.org Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC Message-ID: <CAJ-Vmo=rmvfrP8o%2BH=s5Eg%2BpEBP-Z21ZUQkrwydwOTz-3pMC8w@mail.gmail.com> In-Reply-To: <DDCDD48E-DC96-4EAE-B84C-797D2A58CDE6@hostpoint.ch> References: <6908B498-6978-4995-B081-8D504ECB5C0A@hostpoint.ch> <007F7A73-75F6-48A6-9C01-E7C179CDA48A@hostpoint.ch> <CAJ-Vmo=36Ob0NSeFVV4goLsaca7Aqc9B0zdPvYWEcNmBPsk40Q@mail.gmail.com> <DDCDD48E-DC96-4EAE-B84C-797D2A58CDE6@hostpoint.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 November 2012 02:39, Markus Gebert <markus.gebert@hostpoint.ch> wrote: > > On 14.11.2012, at 02:12, Adrian Chadd <adrian@freebsd.org> wrote: > > Oh lordie, just hack the kernel to make IP_BINDANY usable by any uid, > not just root. > > I was hoping that capabilitiies would actually be useful these days, > but apparently not. :( > > Then you can stop this FD exchange nonsense and this problem should go away. > :) > > > Thanks for the suggestion, I'll probably do that regardless of a fix to the > unp_gc problem, because it's indeed unnecessary overhead in our scenario. > Still that's a workaround you most probably don't want if you have untrusted > users on the system or you end up hacking in something comparable to > security.mac.seeotheruids.specificgid. Yeah. I was hoping that capabilities would be settable from userland these days. I remember talking with Robert (CC'ed) about this when Julian/I threw this into FreeBSD. He wanted me to put it behind a capability (which I did) but there was no way for userland to grant a process this capability. Robert - is there any way these days to grant capabilities to userland processes? Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=rmvfrP8o%2BH=s5Eg%2BpEBP-Z21ZUQkrwydwOTz-3pMC8w>