> > > > 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/ > > Perhaps I'm misunderstanding, but that is talking about a specific set > of problems that I don't think polkit was actually designed to > address. Polkit is basically for authenticating applications via > users, not the applications themselves. If I am running app foo, and > app foo wants to inhibit hibernation; polkit is there to ask 'hey is > antarus allowed to inhibit hibernation? Does antarus need to auth to > do so? Is antarus already authenticated? Now one may say 'hey but I > only want certain applications to hibernate' and while that may be an > interesting problem...I don't think the existing polkit intends to > solve it. >
The point is that it is inferior in every way and so pointlessly causing more work and other problems not to mention guaranteed increased security risk having extra code constantly running as root. Why was it started, rather than contributing to sudo. > > > > > >> 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. > > One could say that 'a discrete set of APIs will be no match for > the..fined grain control that is the command line!' I would agree. I > don't agree that this is a one-size fits all deal though. There can be > a command line AND an API. I'd rather grant my users 'access to the > install authenticated packages action' than have to own a complex sudo > rule. > How about uncommenting a line that does so. All you are buying into is a default setup. > I don't understand 'the APIs that coders will learn instead of C.' Can > you elaborate? Polkit has a C api... > It has an api that is simply not needed? Small tools are better. > I don't understand how the code will 'not be well designed to the > application at hand.' I mean ideally the API and the CLI are > essentially just wrappers around the same library of functions. > If you search for sites that evaluate polkit you will see that it is considered to encourage granting more permissions than necessary rather than coding a specific tool. > Its unclear how polkit is 'hard'. Now it *is* new, and I will concede > you will have to read some manpages. However i don't think the > concepts are difficult. Man pages won't help with polkit and it actually generally ships with no configs by default. > There are plenty of helpers (pkcheck springs > to mind) that assist the user in figuring out what is 'allowed'. I know about pkaction, the problem is that the actions tells you next to nothing about what is actually allowed. I haven't time to dig out one of the rediculous comments from the source now unfortunately. With small tools it's much better all round. >The > configuration for polkit is all in /usr/share and /etc. The configs > are configurable..again in /etc. This is not something I would term > 'challenging.' > Generally there aren't any rules files, the defaults are built in and your expected to use a webbrowser, even on a server?!?! You shouldn't run lynx never mind X on a server. If some configs are in /usr/share rather than /etc perhaps that explains why one tutorial said so and it has no effect on some systems. > > > > 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. > > Its not a matter of many-eyes. It is a matter of 'some other guy is in > charge of maintaining that component.' It means I can focus on stuff > that matters, and not focus on 'wrappers to make random things work.' That can apply to sudo, would be more secure and cause less problems and you see why I brought it up and asked why not, because that should be the case. > Is the polkit maintain any less 'trustworthy' than the gnome > maintainers? the kde maintainers? the kernel maintainers? At the end > of the day my machines are running software from thousands of > contributors. > I think that has been demonstrated and we are talking about root code and sudo is never running as such. > > > >> 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. > > Er, apt-get update downloads new Packages files, it doesn't install > any additional software. apt-get *upgrade* will. These are separate > *actions*. > /usr/bin/sudo /usr/bin/aptitude /usr/bin/sudo -t experimental install iceweasel You could even make synaptic use a _synaptic group just to install. > > > > 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. > > Look if you don't trust polkit, or you dislike it, or you just don't > have time to understand how it works; that is cool. 18 months ago I > was in the same camp. Polkit is not strictly required. But don't go > spouting about how much it sucks unless you have actually *used* it. > I do understand and I asked on the kde lists how to get kde 4.9 to switch back to using kdesudo by default. NOONE replied except a gentoo user called Duncan who was interested in the answer himself and was very helpful and told me how to remove rather than disable polkit if I don't mind compiling obviously. I worry more problems will be brought to bear and a lot of development done that could have been spent better. > In some cases (like most places where multiple users are present) it > is in fact terrible. We wanted to do some 'unique' things with > mounting of USB hardware with polkit (and udisks) and found it > basically impossible to make work over ssh. I ended up going with the > 'sudo make me a sandwich' route. Sometimes that is necessary. > Same here but not over ssh, though some of the functionality has since been put back. We have digressed from the point though, unless there is a real need for polkit that I have missed? I've read Polkit's predecessor was abandoned because it was a bad development and yet has been basically renamed to get away from the flak. Is it just misunderstanding of what sudo has to offer that drives polkit, that seems rife wherever polkit and sudo are mentioned in lists, often to the point of confusing sudo with su. It may become a real shame in history that many threads seem to believe sudo makes systems less secure when in fact it is polkit. So does anyone know for sure why sudoers with rules in aside from allow all were dropped and if that was a bad decision? I imagine users are better at avoiding sudo pitfalls these days and so maybe it should be brought back? -- _______________________________________________________________________ '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) _______________________________________________________________________
