[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Andy Lutomirski]

On Apr 17, 2015 4:53 AM, "Djalal Harouni" <tixxdz at opendz.org> wrote:
>
> Hi Andy,
>
> On Thu, Apr 16, 2015 at 12:30:28PM -0700, Andy Lutomirski wrote:
> > On Thu, Apr 16, 2015 at 11:23 AM, Lennart Poettering
> > <lennart at poettering.net> wrote:
> [...]
> > AFAICT this piece of kdbus code serves to enable a rather odd way to
> > write privilege-separated services to change the time and kill
> > processes.  The cost is complex security code that, at best, fails
> > secure in the presence of different user namespaces, and the cost also
> > involves touching a global refcount for each message sent (this might
> > be the *only* thing that would reference init_user_ns's refcount when
> > sending).  Oh yeah, the cost is also ABI crap -- if, say, my
> The global ref-counts on metadata is just a workaround due to userns and
> caps. I actually thought we already sorted that out?
>
>  https://lkml.org/lkml/2015/3/25/702
>
> Hmm there are other paths that refs user_ns, the mqueue notification
> perhaps ?
>
> Please note that we also have _per_ user quota accounting, the trade off
> of accouting prevents further performance penalties on other bus
> operations. Referring to performance critical code, this code path can
> just be ignored by to not opt-in for KDBUS_ATTACH_CAPS which is the
> default behaviour.

Quoting that link:

> It's conditional on KDBUS_ATTACH_CAPS, anyway.

Fair enough.

[end quote]

I don't believe it'll be usefully conditional.  Systemd is pretty
clearly planning on using it, so you get a silly, if small,
performance hit.

My point here is that there's no real shortage of downsides to this
scheme, and there still appears to be little to no benefit.

--Andy

>
> Thanks!
>
> --
> Djalal Harouni
> http://opendz.org