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 1331422 - UID for geoclue user
Summary: UID for geoclue user
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: setup
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ondrej Vasik
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-28 13:33 UTC by Zeeshan Ali
Modified: 2016-09-20 01:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-13 16:08:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Zeeshan Ali 2016-04-28 13:33:13 UTC 
I created a new build of geoclue2 for bug#1285479 and seems RPMDiff tool all of a sudden doesn't like my package to be creating 'geoclue' account without specifying a particular UID. The documentation about the error:

https://docs.engineering.redhat.com/display/HTD/rpmdiff-rpm-scripts-and-triggers

says that we should be doing this through 'setup' package, hence I'm filling this bug to try to resolve the issue.

The user in question is the account used for running geoclue2 system service and hence handles user's location and also sends out nearby wifi networks data to mozilla location services, hence I chose not to ignore this error, as per the guideline in documentation.
Comment 2 Ondrej Vasik 2016-04-29 04:25:18 UTC 
Thanks for report and not ignoring the rpmdiff error, however rpmdiff is a bit overaggressive about this static uid/gid suggestion for system accounts. Nowadays, I'm no longer allowed to assign static id myself. It has to be handled through fpc - see https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation - they require justification why static id is preferred over dynamic one.

From the brief description, it looks like dynamic system id should be ok in this case, but maybe I miss how can different uid/gid for this service across systems influence its security and functionality.

Please add the link to the fpc ticket into this bugzilla, if you decide to file fpc ticket. If you decide to not do so, please close this bugzilla notabug. Thanks in advance.
Comment 3 Zeeshan Ali 2016-05-13 16:08:28 UTC 
(In reply to Ondrej Vasik from comment #2)
> Thanks for report and not ignoring the rpmdiff error, however rpmdiff is a
> bit overaggressive about this static uid/gid suggestion for system accounts.
> Nowadays, I'm no longer allowed to assign static id myself. It has to be
> handled through fpc - see
> https://fedoraproject.org/wiki/Packaging:
> UsersAndGroups#Soft_static_allocation - they require justification why
> static id is preferred over dynamic one.
> 
> From the brief description, it looks like dynamic system id should be ok in
> this case, but maybe I miss how can different uid/gid for this service
> across systems influence its security and functionality.
>
> Please add the link to the fpc ticket into this bugzilla, if you decide to
> file fpc ticket. If you decide to not do so, please close this bugzilla
> notabug. Thanks in advance.

Sorry for late reply. If you think it's OK in this case to use dynamic ID, I'm fine with it too. :) Thanks.
Note You need to log in before you can comment on or make changes to this bug.