Bug 2222810

Re-assigning the product for analysis. SSSD handles the implementation of the overrides.

Hello Tomasz

I think that there is misunderstanding of how the ID overrides works. It is not expected that the overridden ID is automatically resolvable.
It is on purpose and you may want to override GID to an existing group 


(In reply to Tomasz Kepczynski from comment #0)
> - user tomek has primary group id of 18519 - overridden
So far so good


> - but it is NOT resolvable back to group name
That is expected as I mentioned above. But you can create new group (in IPA or locally) where
that new GID will resolve to.


> - additional note - 20000000 is gid for group admins and it is NOT resolved
> (this might be a separate bug as it was NOT overridden)
Unfortunately there is not enough information to judge this. Can you attach SSSD logs with debug_level set to 9
where this operation fails?


> 
> Try to override tomek group:
> 
> vesemir:~> ipa idoverridegroup-add TEST tomek --gid=18519
> ipa: ERROR: invalid 'IPA object': system IPA objects (e.g. system groups,
> user private groups) cannot be overridden
> 
Private groups are very special and they can't be override by design, so this is also expected.
Could you explain in more detail what you want to achieve.

Just for the completeness here is an ID Views documentation 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/using-an-id-view-to-override-a-user-attribute-value-on-an-idm-client_managing-users-groups-hosts

HTH
Tomáš

I want to override the user so its primary group id is also overridden and resolved back to the group name equal to username.(In reply to Tomas Halman from comment #5)
> > Try to override tomek group:
> > 
> > vesemir:~> ipa idoverridegroup-add TEST tomek --gid=18519
> > ipa: ERROR: invalid 'IPA object': system IPA objects (e.g. system groups,
> > user private groups) cannot be overridden
> > 
> Private groups are very special and they can't be override by design, so
> this is also expected.
Could you explain why this decision was made because this is EXACTLY want I need to do?

> Could you explain in more detail what you want to achieve.
I want to override the user so its primary group id is also overridden and resolved back to the group name equal to username.

Basically on one system in the domain the user needs to have different uid and gid where gid is a private user group and its gid = overridden uid.

(In reply to Tomasz Kepczynski from comment #6)

> > Could you explain in more detail what you want to achieve.
> I want to override the user so its primary group id is also overridden and
> resolved back to the group name equal to username.
> 
> Basically on one system in the domain the user needs to have different uid
> and gid where gid is a private user group and its gid = overridden uid.

If I understand correctly, only missing part is resolving group id to name.

You can achieve this by creating local group of the same name (tomek) with GID 18519.

If you prefer to do it on IPA side, you have to create group with GID 18519 with a different name - for
example tomek2. Then add mapping of this group to the group name that you need `ipa idoverridegroup-add TEST tomek2 --group-name tomek`

HTH
Tomáš

Hi Tomasz, do you need any further assistance?

I just don't understand the artificial limitation of the override mechanism which doesn't allow to propagate the private group id semantics to the system where the override is applied. Hence my question (yes, I am repeating myself): why doesn't override allow private group to be overridden?

The way I see it is what IPA currently imlements is "half" of the solution.

IPA allows to override private user id and primary group id of the user to the IDENTICAL values. This is what private groups are ALL ABOUT. Where it fails short is that it DOES NOT allow to override the group id of THAT affected user to his now primary group id. While I can undestatnd two extremes:
1. Do not allow overrides for users with private groups
2. Automatically OVERRIDE primary group id of the user with private group to his overridden user id AND automatically OVERRIDE his primary group id to the same
I do not understand the reasoning behind current solution which causes the user to no longer belong to private group after an override.

Please consider architectural discussion about it because currently in my opinion it is flawed. Other than that it seems to be more feature request than the bug so treat it as appropriate.

BTW, this suggestion:

> You can achieve this by creating local group of the same name (tomek) with GID 18519.

goes contrary to the overrides design goals, to move overrides from the local systems (high maintenance involvement, each affected system needs to be modified) to the central system (IPA, single database to update, low maintenance cost).

(In reply to Tomasz Kepczynski from comment #10)
> BTW, this suggestion:
> 
> > You can achieve this by creating local group of the same name (tomek) with GID 18519.
> 
> goes contrary to the overrides design goals, to move overrides from the
> local systems (high maintenance involvement, each affected system needs to
> be modified) to the central system (IPA, single database to update, low
> maintenance cost).

This is why I provided also solution on IPA side.

Here is the summary as I understand it:

Customer expects that if an override for user's gid number is created, that there is also automatically created mapping for name of this new gid value so it can be resolved to the original group name.
So if we perform `id <user>` we can see his original private group name. Currently we se the newly mapped gidNumber or name of group that has this gidNumber.


Customer says:
> I just don't understand the artificial limitation of the override mechanism which doesn't allow to propagate the private group id semantics to the system where the override is applied. Hence my question (yes, I am repeating myself): > why doesn't override allow private group to be overridden?

Just to be clear, private group id is overwritten and user has this new gidNumber on target machine. Just translation of this newly assigned gid to its original group name does not happen on the target machine.


In my opinion, such automatic translation may work in your use-case, but it might break another use cases.

- Consider situation where you map gidNumber to existing one - then on the target machine there will be two groups with the same gidNumber but different name
- Consider legacy system where mutliple users have the same private group called "users" - if you create multiple override like this, to which group should be the gid mapped
- Consider network storage - If we just create this artificial mapping without actually creating also group with this gidNumber, then user may create files on one system and the group ownership will be broken on another machine.



@Alexander,

Tomasz also asked about ID override design documentation. Do you know about it or can you comment on this request?

Thanks
Tom

(In reply to Tomas Halman from comment #12)
> In my opinion, such automatic translation may work in your use-case, but it
> might break another use cases.
> 
> - Consider situation where you map gidNumber to existing one - then on the
> target machine there will be two groups with the same gidNumber but
> different name
This still can be done in cases where private group id is not involved at all.
If you consider this dangerous in context of private gid override, you should do
so in other cases as well. And regardless, the normal nss resolution order, as
specified in /etc/nsswitch.conf should resolve this.
> - Consider legacy system where mutliple users have the same private group
> called "users" - if you create multiple override like this, to which group
> should be the gid mapped
If the primary gid == user id then group name := user name. The legacy
*users* group has nothing to do with that.
> - Consider network storage - If we just create this artificial mapping
> without actually creating also group with this gidNumber, then user may
> create files on one system and the group ownership will be broken on another
> machine.
Network storage is confusing already in this context. Let me show you:
The following are against nfs file system on a system with the discussed override
applied:
visenna:~> ls -ln /nfs/home/tomek/aaa.txt 
-rw-r--r-- 1 18519 20000003 3304 wrz 10 22:28 /nfs/home/tomek/aaa.txt
visenna:~> ls -l /nfs/home/tomek/aaa.txt 
-rw-r--r-- 1 tomek tomek 3304 wrz 10 22:28 /nfs/home/tomek/aaa.txt

As you can see the user id has been overridden and maps back to
the name but the same does not apply to group id.

You can see below the same listing from the system without override:
vesemir:~> ls -l aaa.txt 
-rw-r--r--. 1 tomek tomek 3304 09-10 22:28 aaa.txt
vesemir:~> ls -ln aaa.txt 
-rw-r--r--. 1 20000003 20000003 3304 09-10 22:28 aaa.txt

I am really not sure if we should see this uid translation here (but please
note this is NFS with kerberos here at play, this may be then expected
by the virtue of nfs id mapping). Anyway - if this can be done for
uid, there should be no problem with gid here as well. And as you can see
the numeric value on the system WITHOUT override seems to be right.

And one final note - to the best of my understanding, the philosophy
on Unix is to give control to the user. You cannot predict and prevent
all of the corner cases here, the users are too creative (looking
at myself :)). Just give them some credit and trust, don't build
Windows and Gates around them :).

ID Views design is documented at https://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust.html#id-views

FreeIPA part for supporting auto private group design is https://freeipa.readthedocs.io/en/latest/designs/adtrust/auto-private-groups.html

Thanks for the pointers.

I honestly admit I haven't read the documents from top to bottom but as far as I can tell:

1. The first document is pretty explicit: "It must be possible to add, display, modify and delete an override object for any trusted user or group in any view." I don't know what "trusted" user or group means but I assume it equally applies to both AD and IPA users and groups. I don't see any mention of "private" word in the document so I guess the prohibition of private user group doesn't come from there.
2. auto_private_groups sssd.conf option doesn't seem to be mentioned in the above document. It CAN probably be used to achieve what I want by setting it to true but this again moves this back to IPA client.
3. auto_private_groups seems to pre-date id overrides. And it seems to be sssd feature, not the IPA feature. Did anyone consider how these two features interact with each other? In what order are they applied? How changing auto_private_groups on the client affects id overrides?

And one last thought. There still is sss_override command (which doesn't work for IPA domains but that's irrelevant). If it was possible to override private user group to match overridden primary group id with user name using that command before id overrides were introduced then I would seriously consider allowing this functionality in the id overrides. That's unfortunately something I cannot test.

Yeah, writing software is hard.

It is the other way around. Auto-private groups in IPA is a relatively new feature. It was added in 2021. ID views were first implemented in 2014. Hence, the design document from 2014 has no mentioning of auto-private groups from future.

Changing anything on the client is by definition affects only that client.

ID overrides looked up by the clients, for client-specific views, default trust view is looked up by the IPA servers and results inherited by all clients without them knowing where the ID override comes from in that case.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.