Am I the only one that thinks policykit is retarded?

[duby229]

I mean the damn thing enforces pebkac to an extreme. Who ever wrote obviously never worked in an environment with more than a few people. When you get forced to enter a root password for every little thing, somebody around you is going to get that password, it's inevitable... It's fucking retarded....

[duby229]

All I'm saying is it damn sure ain't secure. Asking for a root password is -NOT- in any possible way a security measure, it is a very serious security flaw. Policykit -needs- replaced ASAP.

[computerquip]

All I'm saying is it damn sure ain't secure. Asking for a root password is -NOT- in any possible way a security measure, it is a very serious security flaw. Policykit -needs- replaced ASAP.

It doesn't need to ask for a root password nor is that all it can do by far. Stop trying to incite a mob based on fallacy, the fuck is wrong with you.

[duby229]

It doesn't need to ask for a root password nor is that all it can do by far. Stop trying to incite a mob based on fallacy, the fuck is wrong with you.

Are you trying to say policykit doesn't prompt for a root password constantly for every little thing? Oh yes the fuck it does, and it's a fucking -terrible- idea!! Wtf is wrong with you that you'd think that's a good idea?

[oiaohm]

Are you trying to say policykit doesn't prompt for a root password constantly for every little thing? Oh yes the fuck it does, and it's a fucking -terrible- idea!! Wtf is wrong with you that you'd think that's a good idea?

This problem is not policykit design. This problem is policykit configuration.

Lets be real if policykit in fact prompted you for every little thing you could have 6 requests for password just on login and a few thousand per min of running. Reality is policykit is in fact being very silent.

https://wiki.archlinux.org/index.php/Polkit

Policykit pops up when you are attempting to do something your user is not configured to-do without a password or simple not configured to-do at all. If your user is configured that you are meant to be able to modify packages in policykit without a password you will not see a password dialogue when you do that same with any other action.

Really duby229 you are the normal since you are getting dialogs and you are not willing to look up how to turn them off the program providing the dialogs has to be broken. Policykit is not broken. Distribution policykit configuration is down right conservative. The reality is policykit can be configured from conservative to absolutely liberal. When I say absolutely liberal you add one file to policykit rules and no matter the action you do the result is you never see a policykit window and everything is just straight up approved.

I do have 1 fault with policykit is a lack of a option to just show a window with a yes/no to approve action without a password this is not a big enough fault to scrap the complete thing and start over.

I do have many faults with distribution provided default policykit configuration for being annoying so I change the settings so in general usage I don't see any policykit windows.

[nanonyme]

This problem is not policykit design. This problem is policykit configuration.

Lets be real if policykit in fact prompted you for every little thing you could have 6 requests for password just on login and a few thousand per min of running. Reality is policykit is in fact being very silent.

https://wiki.archlinux.org/index.php/Polkit

Policykit pops up when you are attempting to do something your user is not configured to-do without a password or simple not configured to-do at all. If your user is configured that you are meant to be able to modify packages in policykit without a password you will not see a password dialogue when you do that same with any other action.

Really duby229 you are the normal since you are getting dialogs and you are not willing to look up how to turn them off the program providing the dialogs has to be broken. Policykit is not broken. Distribution policykit configuration is down right conservative. The reality is policykit can be configured from conservative to absolutely liberal. When I say absolutely liberal you add one file to policykit rules and no matter the action you do the result is you never see a policykit window and everything is just straight up approved.

I do have 1 fault with policykit is a lack of a option to just show a window with a yes/no to approve action without a password this is not a big enough fault to scrap the complete thing and start over.

I do have many faults with distribution provided default policykit configuration for being annoying so I change the settings so in general usage I don't see any policykit windows.

I think it's good it requires you to authenticate. It prevents accidental consents (a la Windows) fairly effectively.

[duby229]

I do set up polkit to my needs, but it's overly complicated. As a Gentoo user it leaves upstream defaults in place on purpose, which is almost always the best choice. But in the case of policykit, those defaults are fucking retarded. Perhaps you're right that polkit doesn't need replaced per say, but at the barest minimum it desperately needs new leadership. As is it's most definitely a pebkac nightmare... 💯

[duby229]

All I'm saying is -BECAUSE- of policykit, it would be nearly impossible to keep a root password private. That's a serious flaw. It's almost certainly THEE most serious flaw in all of Linux right now.

[oiaohm]

I do set up polkit to my needs, but it's overly complicated. As a Gentoo user it leaves upstream defaults in place on purpose, which is almost always the best choice. But in the case of policykit, those defaults are fucking retarded. Perhaps you're right that polkit doesn't need replaced per say, but at the barest minimum it desperately needs new leadership. As is it's most definitely a pebkac nightmare... 💯

Defaults of policy kit are hard to design. Also most of the configuration of policykit defaults are by applications not by the main policykit leadership. Core engine is the main Policykit developers. Policykit defaults are distributions and application makers.

All I'm saying is -BECAUSE- of policykit, it would be nearly impossible to keep a root password private. That's a serious flaw. It's almost certainly THEE most serious flaw in all of Linux right now.

https://wiki.archlinux.org/index.php/Polkit

If root password leakage is you worry you should have configured policykit. Using the rules javascript of policykit you can make root password absolutely useless todo anything policykit. Policykit is massively configurable.

Reality is all I see is a person complaining about stuff who is blaming policykit instead of distributions and applications who are the real problems here. Also not understanding how policykit can be configured.

[oiaohm]

I could not make systemd&udev rule work for this script:

#!/bin/bash

if [ ! -e /dev/dvb/adapter0/frontend99 ]
then
gksu -- bash -c 'mv /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend99; mv /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/frontend0'

fi
   
/usr/bin/vlc /home/xfce/Documents/channels.conf

I don't get why using gksu.

https://www.freedesktop.org/software/polkit/docs/0.105/pkexec.1.html

You did a pkexec allow rule before. The moves for these cases can be performed by a script run by pkexec then approved by a policykit file then user not bugged by password request.

There should be a udev way reordering those but I cannot think of it off the top of head.