This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 957852

Summary: Use /etc/login.defs to obtain the first non-system UID
Product: [Fedora] Fedora Reporter: Tomas Heinrich <theinric>
Component: setupAssignee: Ondrej Vasik <ovasik>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: mitr, ovasik, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=717109
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Tomas Heinrich 2013-04-29 13:54:34 EDT
Description of problem:
There are some hard-coded values for UIDs in /etc/{profile,bashrc,csh.cshrc}.
The limits should be obtained dynamically from /etc/login.defs.
For reasoning, see https://fedoraproject.org/wiki/Features/1000SystemAccounts

Version-Release number of selected component (if applicable):
setup-2.8.57-1.fc18.noarch

This is the offending part:

> # By default, we want umask to get set. This sets it for login shell
> # Current threshold for system reserved uid/gids is 200
> # You could check uidgid reservation validity in
> # /usr/share/doc/setup-*/uidgid file
> if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
>     umask 002
> else
>     umask 022
> fi

Since F16, the UIDs for user accounts have values equal to or greater than 1000 and everything lower is static / dynamic system UIDs.
The code excerpt above should be changed to use the value of UID_MIN from /etc/login.defs.
Comment 1 Miloslav Trmač 2013-04-29 14:01:02 EDT
Hardcoding 1000 might be acceptable as well if there are performance concerns.

Or perhaps do

if UID > 1000
  hard-code "user"
else if UID < 200
  hard-code "system"
else check UID_MIN

That should minimize the number of shell invocations impacted.
Comment 2 Ondrej Vasik 2013-04-30 08:28:23 EDT
Thanks for report - however you are probably not corect with UID_MIN - SYS_UID_MIN could be used there - this handles (from some reason) only static system accounts differently (it was doing the same even before the 1000 change (with 100 as limit for umask 022)). This handling definitely needs improvement - I'll see what is the best approach.
Comment 3 Miloslav Trmač 2013-04-30 08:39:56 EDT
No, don't use SYS_*; http://fedoraproject.org/wiki/Features/1000SystemAccounts has explicitly defined that the boundary between system/user accounts is UID_MIN.

(The login.defs configuration allows ambiguous IDs that are neither in the SYS_UID_* nor in the UID_* range; it's important to treat them consistently, i.e. use the same rule for system/user account differentiation everywhere; we have standardized on UID_MIN.)
Comment 4 Miloslav Trmač 2013-04-30 08:41:03 EDT
(In reply to comment #3)
> No, don't use SYS_*;
> http://fedoraproject.org/wiki/Features/1000SystemAccounts has explicitly
> defined that the boundary between system/user accounts is UID_MIN.

Sorry, I misread - if you do want to continue treating statically and dynamically-allocated system accounts differently, SYS_UID_MIN would be fine.

For system/user accounts the right value is UID_MIN, though.
Comment 5 Ondrej Vasik 2013-04-30 10:06:48 EDT
I'll see... I want to check why the static and dynamic parts were treated differently - as it is there for a long time (and honestly - I don't see any reason for it)... IMHO it would be better to make it consistent (system accounts 022, user accounts 002)
Comment 6 Fedora End Of Life 2013-09-16 12:40:20 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 7 Fedora End Of Life 2013-09-17 03:46:54 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 8 Fedora End Of Life 2015-05-29 05:01:47 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Jan Kurik 2015-07-15 10:48:07 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23