Regression: 'usermod -G' fails if user has any remote groups

[mcatanzaro]

We discovered that 140510d breaks usermod -G if the user is a member of any remote groups. Say the user "foo" is a member of remote group "foogroup". We want to add the user to local group "bargroup".

$ usermod -G foogroup:bargroup -- foo

This will fail since 140510d because usermod claims the remote group foogroup does not exist. However, we must specify foogroup because if we do not, then foogroup will be removed. All we want to do is add bargroup while maintaining the existing group foogroup.

This is breaking accountsservice's org.freedesktop.Accounts.User.SetAccountType method, see here for details. A workaround in this case would be to use usermod -aG instead, but that only works when adding groups. There's currently no way to remove a group without specifying all existing groups that we don't want to remove. Avoiding that would require a hypothetical usermod -rG, see #337.

CC @ikerexxe

[hallyn]

Trying to wrap my head around this...

How does usermod remove the user from a remote supplementary group?

[mcatanzaro]

How does usermod remove the user from a remote supplementary group?

I don't know. Apparently it shouldn't be able to, which is what 140510d was trying to fix. Doesn't matter for the purposes of this bug. For this bug, we just need to know that to remove a group with usermod, we have to use usermod -G which requires manually passing every group that is to be not removed, and that is no longer possible after 140510d.

[hallyn]

Well no. I'm obviously missing something here, but if user joe is a member of remote group r1, and you want to add local group l1, and so you do 'usermod -G joe l1', it should not affect joe's membership in r1, since that membership is stored elsewhere.

Obviously something in the statement I'm making above is wrong.

[hallyn]

Are you storing the remote groups in sssd? nis? I haven't touched this stuff before, but will have to set up a test environment.

[mcatanzaro]

Well no. I'm obviously missing something here, but if user joe is a member of remote group r1, and you want to add local group l1, and so you do 'usermod -G joe l1', it should not affect joe's membership in r1, since that membership is stored elsewhere.

I assume that prior to 140510d, it was removing the local understanding of the remote group membership? But I'm just guessing. I really don't know how it works tbh.

Are you storing the remote groups in sssd? nis? I haven't touched this stuff before, but will have to set up a test environment.

I'm using sssd and I assume the remote group membership is somehow tracked by or stored in sssd, yes, though I don't know how it works tbh. I hadn't used enterprise login at all before last week. (I don't know about nis, but it's probably similar?)

I set up a freeipa test environment for the first time last week, and only succeeded due to substantial handholding from somebody who had done it before. It's a little complicated to do for the first time. Note that @ikerexxe is planning to investigate this issue, so you may not need to do so yourself.

[mcatanzaro]

Well no. I'm obviously missing something here, but if user joe is a member of remote group r1, and you want to add local group l1, and so you do 'usermod -G joe l1', it should not affect joe's membership in r1, since that membership is stored elsewhere.

Obviously something in the statement I'm making above is wrong.

Yes. If you want to not remove group r1, you need to do usermod -G r1:l1 joe.

[mcatanzaro]

Yes. If you want to not remove group r1, you need to do usermod -G r1:l1 joe.

(The usermod syntax for adding or removing groups does not distinguish between local and remote groups. usermod -G just replaces your current group membership with whatever is passed to -G.)

[ikerexxe]

IIRC, prior to 140510d when using usermod to add a local user to a network group, the command didn't fail but the group wasn't added. So, in reality it was failing without reporting it.

Moreover, if a local user was already a member of a network group (how this happened in the first place I don't know) and a new local group was to be added you had to use -aG. In this case the user was added to the local group without loosing membership from the network group.

IIUC, the second use case was broken with 140510d.

[olivergs]

The exact use case is: I login with a remote user (a user from an Active Directory). SSSD does its magic and allows the user to login. Then we want to add that remote user to a local group (wheel in this case to be able to sudo, etc.).

As I understood, the accountsservice daemon is using usermod to do that operation, but 140510d prevented to add a remote group to any user.

As the user is a remote user, and it is already a member of that remote group, the command should not avoid to add it to a remote group.

What we were talking last week was to make usermod to not check the group if the user you are modifying is already a member of that group.