Question - PolicyKit

[dawg]

David Zeuthen wrote:
> On Tue, 2008-07-15 at 15:01 -0400, dawg wrote:
>   
>> Sorry, I'm a lost pooch. But anyway...
>>
>> No, I don't buy into that, but I do not want to allow all things to be
>> accessible without a password. There are reasons for those dialogs, or
>> they wouldn't exist. Not everyone wants to allow anyone to access
>> everything. And if the expectation is that no one should need or want
>> the dialog, why not change PolicyKit so that it doesn't ask at all? By
>> your logic, it should all just be assumed, without ever even giving
>> the dialog with the stupid default.
>>     
>
> Uh, that's why you can change the defaults as I explained in the earlier
> mail. See, the defaults are chosen by the application developer. Of
> course some administrators will want to change them. So we provide a
> mechanism (e.g. polkit-action(1)) to do exactly that.
>   
I may have misunderstood you. Changing the default for the checkbox is 
exactly what I want to do. It sounded like you were stating that it was 
only possible to make it so that the "remember" option is *never* shown 
(not what I want).
>   
>> The only problem with the dialog is that you slow down ADMINISTRATORS
>> by making them uncheck the default every time (and even more so if
>> they forget once and then have to fix it through some other dialog).
>> If the "human" or administrator wishes for the authorization to be
>> remembered, they should have to check the box to remember -- because
>> they would only have to do it once! They wouldn't see the dialog
>> again. On the other hand, if the administrator does not want the info
>> to be remembered, he or she will have to uncheck the option every
>> single time.
>>     
>
> Keep in mind that some actions does not come with a "remember
> authorization" check box at all. For example
>
>         $ polkit-action --action org.freedesktop.packagekit.localinstall-untrusted
>         action_id:        org.freedesktop.packagekit.localinstall-untrusted
>         description:      Install untrusted local file
>         message:          Further authentication is required to install an untrusted local file
>         default_any:      no
>         default_inactive: no
>         default_active:   auth_admin
>         
> doesn't.
>
> It's up to the application developer to choose whether the
> authorization. Now, if you as an administrator disagrees with the
> upstream developer simply change the default using polkit-action(1). And
> if you think, for whatever reason, that the upstream developer should
> change it upstream go talk to him. Try to convince him that it doesn't
> make sense users should retain the authorization. 
>   
I was not saying that it doesn't make sense to allow them to retain 
authorization (I *want* it to in some cases), I am only saying it 
doesn't make sense for the checkbox to be ticked by default if it 
doesn't remember that it was unchecked in previous instances.
> I bet in most cases the upstream developer will reject such a feature
> request simply because it doesn't make sense to ask for passwords for
> such mundane things as mounting a disk, installing a signed trusted RPM
> etc. etc. in a consumer style setting where the user is sitting right in
> front of the system.
>   
I agree that it doesn't make sense to ask for passwords for mounting 
disks (in most cases). (Of course it makes perfect sense in certain 
secure environments.) I happily let PolicyKit retain that authorization. 
However, for example, I do *not* want a user to be able to uninstall 
whatever they want. My family is not as familiar with Linux as I am 
(indeed, I've completely broken my system by mistake while uninstalling 
things in the past), but more to the point, someone could uninstall 
security software such as firewalls, etc., which certainly is a security 
concern. It might not even be the end user -- they might simply walk 
away from their station at work or whatnot ever else.
> Think about it. You're asking for a default where the "keep
> authorization" check box is to be unchecked when the dialog comes up.
> That's a terrible default since most people won't read the dialog as you
> point out yourself. So the result is that people will keep being
> interrupted by password dialogs. Which sucks.
>   
I did not say that most people wouldn't read the dialog. But you are 
right, people don't read it if they see it all of the time.

If the checkbox was not defaulted to ticked (as I am suggesting), the 
worst case scenario (with regard to the point you are making) is that 
some stupid users may never bother to change the option. So what? It 
would be their own fault, and, arguably, they would probably eventually 
notice the option. Besides, most people are familiar with the idea of 
checking a box to remember their password if they use the Web on a 
regular basis.

On the other hand, if the user does not read the dialog and the default 
is checked, they will have unwittingly changed a security setting on 
their computer! And you are saying the former is worse?
>   
>> I don't mean to sound like an arrogant ass, but I do not understand
>> how you can't see the point I'm trying to make. The only thing I can
>> possibly think of is that you are assuming the administrator is a
>> separate account or something...? Sure, that may be the case, but
>> there are many situations in which the admin would want to perform an
>> action without logging out the current user or taking the TIME to log
>> in to a second account or use the command line or whatnot ever else.
>>     
>
> Maybe if you could come up with concrete examples of what problems you
> have it would be useful, e.g. in what polkit authentication dialogs
> (need the action name, see Details> in the dialog) do you run into where
> you wish the "retain authorization" checkbox wasn't clicked by default?
>   
I don't want users (for example) to be able to uninstall programs which 
are needed for system stability, security, or so on.

I'm sorry, I do not understand what question or statement you are making 
in parenthesis above...
> (also, please avoid HTML mail and please reply inline, e.g. no top
> posting. Thanks.)
>   
Sorry. I believe I've switched to plain text in this message.
>       David
>   
Nate
>
>
>
>