checks "admin" group membership instead of querying polkit

Status changed to 'Confirmed' because the bug affects multiple users.

language-selector does not identify admins via sudo; like most desktop services, it uses policykit instead, which is configured via /etc/polkit-1/localauthorityconf.d.

On an Ubuntu system, the desktop administrator groups are defined in </etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf>.

Ok, so I added the group I am in as an AdminIdentity in this file. However, in the language selector, the relevant buttons are still grayed out.

I am very confident that my change to /etc/polkit-1/localauthority.conf.d/ is right, because it actually changed something for the user account administration that is also part of gnome-control-center. Previously this would ask me for the root password, now I am able to unlock the settings there with my own password (or one of the other accounts in the new admin group). So this should work for the language selector, too.

I'm seeing the same problem as Philipp. There's some issue with how Language Selector uses PolicyKit. Adding additional admin identities to local authority doesn't authorize them to set system-wide settings in Language Selector. But adding users to the sudo group works.

Here are steps to reproduce:

1. Start with an account (myuser) with no admin privs. (I.e., not in group sudo.) Verify no privs in language selector. Verify that running "pkexec id" prompts for the root password, not the user password.
2. Create a new group containing the user:
        - addgroup --system mygroup
        - adduser myuser mygroup
3. Configure the new group as an admin identity by creating /etc/polkit-1/localauthority.conf.d/60-mygroup.conf with:
        [Configuration]
        AdminIdentities=unix-group:mygroup
4. Verify that "pkexec id" now prompts for the user password rather than root password. This means local authority is now properly configured.
5. Log out and back in again as myuser. Note that the user still doesn't have authorization for language selector.
6. Add the user to group sudo. (adduser myuser sudo).
7. Log out and back in again as myuser. Note that the user now has authorization for lanuage selector.

PolicyKit's checks are mooted by line 145 of /usr/lib/python2.7/dist-packages/LanguageSelector/gtk/GtkLanguageSelector.py, which reads simply:

145 self.is_admin = (os.getuid() == 0 or in_grp_sudo or in_grp_admin)

Later, on line 192:

192 if self.is_admin:
193 self.setupInstallerTreeView()
194 self.updateLanguageView()

Thus the buttons are clickable iff the user launching the utility is in the sudo or admin groups. A quick edit of line 145 to simply read

145 self.is_admin = True #(os.getuid() == 0 or in_grp_sudo or in_grp_admin)

...immediately makes the buttons accessible and semi-functional: I can e.g. select Install / Remove Languages, then click Japanese, then click Apply Changes, and things proceed normally - I get a PolicyKit prompt, give it my password, and get my Japanese support.

I don't understand what kind of change is needed to address the above observations. The user who is created at a fresh 12.04 installation is initially included in the "sudo" Unix group, which gives him or her administrative privileges. If other users are made "administrators" via System Settings -> User Accounts (which tool should be used for the purpose), they are added to the "sudo" Unix group.

Since the "sudo" and "admin" Unix groups are included in 51-ubuntu-admin.conf by default, there is normally no need to edit that file.

@Philipp: Which Unix groups are you included in? You can find out by opening a terminal window and run the "groups" command.

Other users are made 'administrators' via a custom pkla file.

[Configuration]
AdminIdentities=unix-netgroup:REDACTED_NETGROUP_NAME

These users are not in the 'sudo' group, and are not UID 0.

antarus@goats4 $ groups
eng adm cdrom fuse ops guest ops-perm nonconf mrmagoo corp-kernel goobuntu tracker-users prism-users

I am not in the sudo group (my sudo group is empty), but I am a administrator according to polkit.

if you are suggesting that we manually add (via the UI) all the administrators for the thousands of machines we run...I don't think that is really a workable solution.

On 2012-12-13 02:17, Alec Warner wrote:
> Other users are made 'administrators' via a custom pkla file.

How would language-selector know about the existence of such files?

On 2012-12-13 02:17, Alec Warner wrote:
> if you are suggesting that we manually add (via the UI) all the
> administrators for the thousands of machines we run...I don't think that
> is really a workable solution.

Maybe not. But I think it's reasonable to assume that those who grant admin privileges in other ways than via the UI do it in a way that is compatible with how Ubuntu handles these things.

Gunnar, the point here is that the code is checking the wrong thing. Nobody sat down and designed the current behavior. I believe that, in fact policykit *is* the way Ubuntu handles these things.

@Gunnar: As I said in the bug report, this is an installation which uses user accounts and groups from an LDAP directory. There is an LDAP group for all network-wide admins, and I am in this group. This group is enabled for sudo and policykit admin rights in the appropriate config files, and I expect all users within this group to have all available permissions. I certainly don't want to edit code files in /usr/lib to give myself additional rights.

I also don't want do put all admin users into the local groups "sudo" or "admin", because this defeats the whole purpose of an LDAP directory (i.e., I would have to change files on all machines in the network whenever there is a new admin or one leaves). It is also not an option to distribute the groups "sudo" and "admin" via LDAP, because then nothing works on the machine in an emergency when the LDAP server is down (it is generally not recommended to distribute any uids and gids < 1000 via LDAP for this reason).

You are also wrong about the "way that is compatible with how Ubuntu handles these things". Ubuntu uses sudo and policykit, and I am using these ways.

Note that language-selector does not need to know about the existence of any files (and should not), it should just ask policykit whether the user has admin rights. That's the way all other applications work (if they don't use sudo).

Okey, okey, I retreat. ;-) Thanks Thomas and Philipp for the additional input.

@Martin: What's you thoughts on this? Should l-s be changed to query policykit instead of checking unix groups?

> Nobody sat down and designed the current behavior.

Well, checking "admin" group membership long predates the advent of polkit. admin group members are still _the_ fundamental definition of an administrator in Ubuntu; sudo, polkit, etc. all define their privileges based on that in their default configuration.

So if you created a new group that are admins in the sense of "root", but is not called "admin", nothing on the desktop will recognize this at first. This includes language selector, but also things like which .desktop files are presented in the desktop and which aren't, then sudo, and a couple of other places which check group memberships. (You already updated your polkit configuration etc. of course, but that's not sufficient for everything).

That said, if someone wants to change language-selector to query polkit for com.ubuntu.languageselector.setsystemdefaultlanguage instead of checking the group membership , that would be very welcome. It's one of the few remaining places which still directly uses the groups.

I linked an experimental branch to this bug, where I show a first attempt to change language-selector in this respect. It doesn't work, though.

This line (144):
obj = bus.get_object('com.ubuntu.LanguageSelector','/')

results in the error:
Could not get owner of name 'com.ubuntu.LanguageSelector'

If you are versed in Python and Policykit, you probably see in the branch what I tried to do. Any hints about how to move forward would be appreciated.

I'm not sure why this doesn't work, as other parts of the code do the same. However, this is not what you want anyway: This check would already authenticate, i. e. you would get a password prompt right at the startup of l-s just for checking if you are an administrator. Instead, this should query polkit in "no interactivity" mode (no POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION), and check if it gets a "no but you can authorize" result (sorry, can't research the details here).

But with polkit we can probably just drop the whole is_admin check completely. If a non-admin user is starting l-s, the polkit dialog will still allow you to authenticate as another user who is an admin.

Thanks for the hints, Martin. I gave up on ls-dbus-backend, discovered gir1.2-polkit-1.0 and wrote a new function in utils.py. Now the code runs, but there is a tiny problem: AdminPrivileges() always returns True. :(

On 2012-12-23 10:56, Martin Pitt wrote:
> But with polkit we can probably just drop the whole is_admin check
> completely. If a non-admin user is starting l-s, the polkit dialog will
> still allow you to authenticate as another user who is an admin.

Simple indeed, bug would it really be a solution? Even if the polkit dialog allows you to enter the credentials of an admin user, as long as you are a standard user you typically don't know any admin password, do you? Personally I think that the current UI, where the admin only controls are disabled (greyed out) for standard users, is better than letting the user know only by an authentication failure.

Question is if there is a way to make polkit tell whether you can authenticate as the current _user_. Unfortunately the get_is_challenge() method seems to take into account the possibility to enter an admin password...

If we can't make polkit provide the desired information without real authentication attempts, and since this is a GUI issue and not a security issue, maybe a gsettings key could be a sufficient solution to this bug.

try:
    gsettings_value = subprocess.check_output(
      ['gsettings', 'get', 'com.ubuntu.language-selector',
       'no-greyed-out-admin-buttons']).decode().rstrip()
except subprocess.CalledProcessError:
    gsettings_value = 'false'
if gsettings_value == 'true':
    self.is_admin = True
else:
    # find out if user has admin privileges via unix groups
    try:
        in_grp_admin = grp.getgrnam("admin")[2] in os.getgroups()
    except KeyError:
        in_grp_admin = False
    try:
        in_grp_sudo = grp.getgrnam("sudo")[2] in os.getgroups()
    except KeyError:
        in_grp_sudo = False
    self.is_admin = (os.getuid() == 0 or in_grp_sudo or in_grp_admin)

Then, when giving a user admin privileges without using the "sudo" or "admin" unix group, changing the value of the gsettings key for that user would prevent the buttons in question from being greyed out.

Gunnar Hjalmarsson [2012-12-31 14:27 -0000]:
> If we can't make polkit provide the desired information without real
> authentication attempts

This is possible. The polkit API has a flag to enable/disable
interactivity, depending on which you either get a "no, but you can
authenticate", or a "yes" answer.

You can see this on the command line with

  pkcheck --action-id com.ubuntu.languageselector.setsystemdefaultlanguage --process $$

if you additionally specify --allow-user-interaction, you'll get the
password dialog instead.

> Then, when giving a user admin privileges without using the "sudo" or
> "admin" unix group, changing the value of the gsettings key for that
> user would prevent the buttons in question from being greyed out.

Please let's not do that. Being an admin or not is not a configuration
matter, polkit already knows that.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

On 2012-12-31 15:51, Martin Pitt wrote:
> Gunnar Hjalmarsson [2012-12-31 14:27 -0000]:
>> If we can't make polkit provide the desired information without real
>> authentication attempts
>
> This is possible. The polkit API has a flag to enable/disable
> interactivity, depending on which you either get a "no, but you can
> authenticate", or a "yes" answer.

Not enabling interactivity is no longer the problem. If you read comment #17 and check out the latest code in the linked branch, you'll see what I mean.

The problem is that polkit responds with "no, but you can authenticate" (or something like it) also for standard users. Seems like it says "no, but you can authenticate by providing the credentials for an admin user". And that's not what we want to know, is it?

On Mon, Dec 31, 2012 at 06:16:40PM -0000, Gunnar Hjalmarsson wrote:
> The problem is that polkit responds with "no, but you can authenticate"
> (or something like it) also for standard users. Seems like it says "no,
> but you can authenticate by providing the credentials for an admin
> user". And that's not what we want to know, is it?

Yes, it is. That's how polkit works - if the user isn't already authorized,
they are given the option to authenticate as an admin user who does have
permission to make the changes.

On 2012-12-31 20:54, Steve Langasek wrote:
> On Mon, Dec 31, 2012 at 06:16:40PM -0000, Gunnar Hjalmarsson wrote:
>> Seems like it says "no, but you can authenticate by providing the
>> credentials for an admin user". And that's not what we want to
>> know, is it?
>
> Yes, it is. That's how polkit works

Let's not forget the context, please. language-selector contains some buttons for accomplishing tasks that only admin users are allowed to do. Those buttons are greyed out for non-admin users.

It seems to me that polkit is not designed to provide the info necessary to distinguish beforehand between admin and non-admin users. I suppose you agree that the answer "no, but you can authenticate by providing the credentials for an admin user" isn't useful for that purpose. If you don't, I may be missing something.

I would get rid of greying out these buttons completely.

You will never know whether the user is able to authenticate as admin, because you cannot know whether the user knows the password of an admin account if you do not ask for it. In all cases where the buttons are greyed out, but the user would know how to authenticate, this will create frustration.

Furthermore, there is no advantage of having the buttons greyed out. If you want to signal to the user that they require more rights, you can put a lock symbol on them (isn't there an example in the time settings dialogue for this?).

This solution would be the easiest to implement and to use.

philw85: I completely agree. The time settings dialog is a great example for how this should work.

I think it's also fine to just let PolicyKit prompt when it needs to without telling the user beforehand. Average Ubuntu users are going to be admins on their single-user systems, and where users are not admins on their own machines it will still be clear what the problem is.

Dialogs that connect to services that use PolicyKit don't need to be aware PolicyKit exists, and keeping those dialogs unaware of PolicyKit makes them flexible for more exotic configurations. There are so many in-the-middle configurations where the user is almost an admin, but can't do absolutely everything. Maybe the user is configured to be able to change time/language settings and install trusted packages, but isn't allowed to install untrusted packages. My point is that the question "is the user an admin?" is very ambiguous, so it's better to just not ask and let PolicyKit handle it.

Trying to summarize the suggestions so far:

* Ask polkit
I failed to make polkit provide the info we would need. If somebody knows how to do that, it would probably be the best and easiest solution. The code in the linked branch may or may not be useful as a starting point.

* Drop the is_admin check
As is argued for in comment #16, #23 and #24, we could drop the is_admin check. But there is at least one thing that would need to be addressed first in that case:
Besides determining whether some buttons should be greyed out, the is_admin check also controls if language-selector shall look for missing langpacks. If a missing langpack is found, the user is asked if s/he wants to install it. Neither the missing langpack test nor the question would make sense if you don't have permission to install langpacks.
Possibly it's time to reconsider this check each time gnome-language-selector is launched? Considering the planned switch from the language-selector UI to the region capplet in gnome-control-center, this needs to be looked into soon anyway.

* gsettings
As a workaround, if none of the above two options is doable right now, I mentioned in comment #18 the possibility to use gsettings to force the buttons to not be greyed out.

So, how do we proceed?

> The problem is that polkit responds with "no, but you can authenticate" (or something like it) also for standard users.

Hm, I get a different error message depending whether or not the user is an admin:

for my user (which is an admin):
$ pkcheck --action-id com.ubuntu.languageselector.setsystemdefaultlanguage --process $$
polkit\56retains_authorization_after_challenge=1
Authorization requires authentication and -u wasn't passed.

For a test user which isn't admin:
$ pkcheck --action-id com.ubuntu.languageselector.setsystemdefaultlanguage --process $$
Not authorized.

(This implies not using interactivity). So it seems to me that polkit can figure this out correctly?

That doesn't prevent us from allowing to authenticate as a different user when using "interactive" mode of course, but it should be possible to figure out whether the current user is an "admin".

> * Ask polkit

That's still my favourite solution.

> * Drop the is_admin check

Would be confusing UI wise, but still bearable if it isn't going to work any other way.

> * gsettings

Please no. This is just wrong in so many ways.

Thanks!

Thanks, Martin. Unfortunately I can't reproduce your "Not authorized." case:

$ pkcheck --action-id com.ubuntu.languageselector.setsystemdefaultlanguage --process $$
polkit\56retains_authorization_after_challenge=1
Authorization requires authentication and -u wasn't passed.
$ groups
test-std
$ cat /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
[Configuration]
AdminIdentities=unix-group:sudo;unix-group:admin

What kind of 'magic' is it you use? ;-)

I previously just tried this under "su", but I fell into the trap that this looks at allow_inactive, not allow_active. Sorry about that.

I filed an upstream polkit bug to get access to this information, as this is IMHO the only clean way of fixing this. Until then, I suggest to either leave that bug open or always show the "Apply system-wide" buttons as that will at least make the functionality available (but it may not work for non-admins).

I'm disinclined to propose that the is_admin check is dropped, since it would degenerate the UI for a lot of (non-admin) users. I think that the check for missing langpacks would make that route especially bad, and personally I'd prefer to leave the bug open for the time being.

Martin, what's your estimate of how long it will take before the polkit people deal with your bug?

Gunnar Hjalmarsson [2013-02-01 0:49 -0000]:
> Martin, what's your estimate of how long it will take before the polkit
> people deal with your bug?

Really hard to say, it depends on the available time and mood of the
polkit authors. Could be anything from a few days to many weeks; we
should at least get the design settled with upstream, the
implementation is probably rather easy.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Please, drop the is_admin check completely.

I said it already: "you cannot know whether the user knows the password of an admin account if you do not ask for it". If you try guessing, you will inevitable guess wrong sometimes and frustrate the user. This is also true if polkit does the guessing.

If you do not want to confuse user with admin buttons, then, either put a lock symbol on all of them, of grey them out and add a single unlock button just like the time settings dialog.

For the check for missing packages, you can just add a button "check for missing packages", or run the check when the user clicks the unlock button. Or you convert the popup that asks the user into a text and button in the language dialog, something along "Missing packages detect. [<lock icon> Install them]".

This solution is easy to implement, does not require new polkit features, has a clear, obvious, ui, and does not get in the way of users by hiding things from them they would like to see.

Philipp,
Maybe the solution you propose is easy to implement if you know how to do it. I for one don't. Please feel free to provide code.

The language-selector UI is planned to be replaced in the standard Ubuntu distribution by the corresponding UI in gnome-control-center. It will probably happen during the S development cycle. For that reason it would be hard to find an experienced developer who would want to spend a significant amount of time with redesigning language-selector.

Now the S development cycle has passed, and I installed Ubuntu 14.04 and there is still the same dialog, and it has still the same problem. Is there now a chance that this gets revisited?

Hi Philipp!

Right, the language-selector UI will live longer than we thought, and nothing has happened with Martin's freedesktop bug about PolicyKit. I have made a change that I think is a reasonable way to deal with this issue. You won't be prompted to install possible missing language support packages unless you are a unix admin user, though.

This bug was fixed in the package language-selector - 0.131

---------------
language-selector (0.131) utopic; urgency=low

  * LanguageSelector/gtk/GtkLanguageSelector.py, help/C/index.docbook:
    - Make the "Apply System-Wide" and "Install / Remove Languages..."
      buttons sensitive also for standard users (LP: #1008344).
 -- Gunnar Hjalmarsson <email address hidden> Fri, 27 Jun 2014 00:06:00 +0200

Hello Philipp, or anyone else affected,

Accepted language-selector into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/language-selector/0.129.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I have installed language-selector-gnome 0.129.1 from trusty-proposed and - unlike before - when logged in as a standard user, the buttons in question are sensitive and I'm able to make system wide changes if providing an admin password.

This bug was fixed in the package language-selector - 0.129.1

---------------
language-selector (0.129.1) trusty-proposed; urgency=low

  * LanguageSelector/gtk/GtkLanguageSelector.py, help/C/index.docbook:
    - Make the "Apply System-Wide" and "Install / Remove Languages..."
      buttons sensitive also for standard users (LP: #1008344).
 -- Gunnar Hjalmarsson <email address hidden> Fri, 27 Jun 2014 00:36:00 +0200

The verification of the Stable Release Update for language-selector has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.