Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

> > Unless sudo has some config setting that allows access only when
> > logged in via console it isn't really a solution.
> >
> > Rich
> >

man sudoers -> /requiretty

>
> I manage 'thousands' of desktops at Google and we generally like
> polkit.

I never meant it is rubbish as such but I saw it as rediculously
inferior to sudo before I even read this.

http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/


> It is however, designed for graphical UI single-seat systems.
> Its command line support sucks (they only added a CLI auth agent in
> May) and it is not well adopted. Multi-user systems do not work well
> with polkit. Certainly with polkit and dbus you can allow users to
> take more specific action without complex wrappers, setuid scripts, or
> sudo.

Except you can't, it only encourages more coarse grained approaches,
less useful commands available and devs to learn an api rather than C
and simply moves code into a far less secure mechanism and increases the
chance that the code will not be well designed to the task at hand and
running as root. It can be a real pain to work out exactly what polkit
allows and you cannot just edit it to suit your application and it
completely ignores the existing unix security technologies with
brilliant track records.

You could try to argue that many eyes will look at a central piece of
code but in fact less implementations will likely mean less eyes and
just assumption that a guy who got JS through as a config language has
everything covered. Granted, unmaintained code running as root may be
higher with sudo but if it needs maintaining, should it be running as
root at all or is it actually simply doing too much.

> My package manager can have a polkit action like 'install a
> signed package' and I can grant the user access to do that, but not
> access to install unsigned packages (root exploit there...) or run
> other dangerous apt commands. It comes built into apt, so I don't have
> to write extra wrappers.

That would be the default and wouldn't even need the command line
argument control of sudo. Just allowing updates is apt-get update.

In fact I have a debian system where experimental iceweasel is
installable but nothing else. I have an Arch system where the only
kernel updateable is a signed by me when offline kernel and polkit is
disabled as I don't have the time to keep track of what it is
permitting and code comments weren't helpful there.

Sudo even supports regex!

p.s. apt should be downloading as an _apt user, simply as best
practice before adding polkit support ;-)

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________