:: Re: [DNG] why is polkit needed?
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Hendrik Boom
日付:  
To: dng
題目: Re: [DNG] why is polkit needed?
On Tue, Feb 25, 2020 at 03:05:27AM -0500, Steve Litt wrote:
> On Mon, 24 Feb 2020 12:21:16 +0000
> Daniel Abrecht via Dng <dng@???> wrote:
>
>
> > So next, why is dbus needed?
> > dbus is a message bus. There usually is one for the whole system, and
> > one for each session.
> > There are various uses and missuses for it, but I think the most
> > crucial things are:
> > * Notify any process interested in something of these things.
> > * Tell other programs which can do something to do something.
>
> The cost is the world's biggest modularity global variable. Everyone
> can write it, everyone can read it. Yeah, there are ways of aiming a
> dbus message at a specific process (I think), but just tracing stuff
> through dbus is incredibly daunting.
>
> > This can be useful for various things, for example:
> > * A program may want to now if a device got rotated, so it can
> > rotate a screen.
>
> Or, you can use dmenu to call a script that rotates the screen. It's
> not automagical, but it gets the ultimate railroad switchyard dbus out
> of the loop.
>
> > * A wlan management gui may want to tell it's daemon that it shall
> > connect to a wlan, and it may want to know what connections it
> > already has and manages.
>
> Sockets (You address this later).
>
> > * A phone call application may want to ring when a call arrives, or
> > it may want to let the user initiate a call.
>
> I don't understand the relationship between this one and dbus. Phone
> call comes in, the app decides what to do.
>
> >
> > Now, those examples are mainly things that would need the system bus.
> > I couldn't come up with a good example solely within a user
> > session/bus, but I'm sure these exist too, especially because dbus
> > doesn't need a graphical session.
> >
> > And with that, back to polkit.
>
> My understanding is that the systemd folks have coopted/kidnapped
> polkit. If that's true, my life would be simpler doing a few things
> manually, or writing a few more shellscripts.
>
> > It'd be bad if just
> > everyone/everything could do system level stuff, so per default,
> > noone can. But that would make dbus useless for a lot of things.
> > This is the problem polkit is there to solve, there are config files
> > specifying who (user, group, etc.) can see/use which methods calls,
> > signals/messages, etc.
>
> I can't think of it at a moment's notice, but there's got to be a
> better way than the global switchyard dbus and the systemd coopted
> polkit.
> >
> > Without dbus, applications & daemons could do similar things using
> > unix sockets. However, then, every application would need their own
> > socket, permission management, configs, etc.
>
> The preceding is true only if every app needed to be in every other
> app's business. For the vast majority of them, this just isn't true.
> For the few that need this, there are sockets, fifos, and signals.
>
>
> > This would have the same
> > security implications as just using dbus, which also just uses unix
> > sockets, but would leave a bigger attack surface, and a lot of
> > scattered security critical configs with different formats.
>
> If every app required it. In a client-server situation, the user of the
> server would need to be in a specific group. If it's even that
> important. I don't really care if somebody else gets into my mplayer
> fifo.
>
> >
> > Now, there is also the approach of using a suid binary for the
> > privileged stuff. As a good and bad thing, just like sudo, this can't
> > escape a container, unlike a unix socket passed to one could.
> > However, it would leave the problem of a bigger attack surface, and a
> > lot of scattered security critical configs with different formats,
> > and is very difficult to get right.
>
> I think suid binaries have fallen out of favor, for the reasons you
> mention.
>
> In summary, I would fully agree with you if everything absolutely had
> to talk to everything else. But such permiscuous talking leads to all
> sorts of problems. Encapsulation is a wonderful thing for stability and
> maintainability.


Which is the reason for a capability architecture. Is there anything
resembling that in GNU/Linux userspace?

-- hendrik

>
> SteveT
>
> Steve Litt
> February 2020 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/thrive
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng