RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1283675 - The kdcproxy user should be created in rpm installation time, and ideally with some soft static uid
Summary: The kdcproxy user should be created in rpm installation time, and ideally wit...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-19 14:44 UTC by Jan Pazdziora
Modified: 2023-09-14 03:13 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-22 11:37:42 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jan Pazdziora 2015-11-19 14:44:23 UTC 
Description of problem:

When ipa-server-install is run, records

  kdcproxy:x:388:388:IPA KDC Proxy User:/var/lib/kdcproxy:/sbin/nologin
  kdcproxy:x:388:

get created in /etc/passwd and /etc/group.

It'd be useful if the user was created at rpm installation time, per

  https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Dynamic_allocation

or even using soft static allocation.

On every system the uid/gid might be different, leading to potential leak when for example in containers data volumes get used with different images.

In understand the kdcproxy user currently does not own any files besides its home directory /var/lib/kdcproxy but it might change (the wsgi application can start storing cache files, etc).

Version-Release number of selected component (if applicable):

#  rpm -qf /usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py
ipa-server-4.2.0-15.el7.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. Check /etc/passwd.
2. Run ipa-server-install.
3. Check /etc/passwd.

Actual results:

New record was created.

Expected results:

No new record was created because it was already there.

Additional info:
Comment 1 Petr Vobornik 2015-11-19 16:29:18 UTC 
Christian, you already worked on issue related to kdcproxy proxy user. What was the result? Is it connected?
Comment 2 Jan Cholasta 2015-11-20 06:45:58 UTC 
Note that the same applies to the sssd and dirsrv users, which are created during ipa-server-install as well. The dirsrv user is created by us, but I don't know who creates the sssd user. Maybe authconfig?
Comment 3 Jan Pazdziora 2015-11-20 07:09:02 UTC 
(In reply to Jan Cholasta from comment #2)
> Note that the same applies to the sssd and dirsrv users, which are created
> during ipa-server-install as well. The dirsrv user is created by us, but I
> don't know who creates the sssd user. Maybe authconfig?

The sssd user comes from sssd-common -- bug 1265099 tracks the soft allocation aspect.

The dirsrv soft allocation is in bug 1143066.
Comment 4 Jan Pazdziora 2015-11-30 10:26:02 UTC 
I propose soft-allocated uid/git 288 which according to /usr/share/doc/setup/uidgid from setup-2.9.8-2.fc23.noarch is free.
Comment 5 Petr Vobornik 2015-12-14 09:47:27 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5545
Comment 11 Alexander Bokovoy 2019-07-30 11:42:50 UTC 
We probably can use systemd-sysusers to request a soft ID. We need to investigate the current status of allocating these IDs on Linux distros.
Comment 12 Christian Heimes 2020-05-20 09:33:44 UTC 
It seems like systemd-sysusers.service is not used by Fedora. The service is disabled on my test system:

# systemctl status systemd-sysusers.service
● systemd-sysusers.service - Create System Users
     Loaded: loaded (/usr/lib/systemd/system/systemd-sysusers.service; static; vendor preset: disabled)
     Active: inactive (dead)
  Condition: start condition failed at Wed 2020-05-20 05:27:33 EDT; 2s ago
             └─ ConditionNeedsUpdate=/etc was not met
       Docs: man:sysusers.d(5)
             man:systemd-sysusers.service(8)

I dropped a file in /usr/lib/sysusers.d/ and started the service. The new user was NOT created and journald for systemd-sysusers showed "Condition check resulted in Create System Users being skipped".


systemd-sysuser won't solve the issue of pre-allocated UID/GID for us, too. https://www.freedesktop.org/software/systemd/man/sysusers.d.html documents the ID column as "Specify "-" for automatic UID/GID allocation for the user or group (this is strongly recommended unless it is strictly necessary to use a specific UID or GID)". That sounds like we still have to get a preallocated UID from FESCO.
Comment 16 Petr Čech 2020-10-22 11:37:42 UTC 
This BZ has been evaluated multiple times over the last several years and we assessed that it is a valuable request to keep in the backlog and address it at some point in future. Time showed that we did not have such capacity, nor have it now nor will have in the foreseeable future. In such a situation keeping it in the backlog is misleading and setting the wrong expectation that we will be able to address it. Unfortunately we will not. To reflect this we are closing this BZ. If you disagree with the decision please reopen or open a new support case and create a new BZ. However this does not guarantee that the request will not be closed during the triage as we are currently applying much more rigor to what we actually can accomplish in the foreseeable future. Contributions and collaboration in the upstream community and CentOS Stream is always welcome!
Thank you for understanding.
Red Hat Enterprise Linux Identity Management Team
Comment 17 Red Hat Bugzilla 2023-09-14 03:13:20 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.