Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 207147 - system users are created with uids/gids in user range
system users are created with uids/gids in user range
Status: CLOSED DUPLICATE of bug 202614
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Installer (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Suchý
Corey Welton
Depends On:
Blocks: sat531-uid
  Show dependency treegraph
Reported: 2006-09-19 14:06 EDT by Matthew Booth
Modified: 2009-09-11 07:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-11 07:33:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Booth 2006-09-19 14:06:04 EDT
Description of problem:

On my newly installed satellite, I have the following users:
nocpulse:x:502:502:NOCpulse user:/home/nocpulse:/bin/bash
nocops:x:503:503:NOCpulse Ops:/home/nocops:/bin/bash

There is an account restriction in system-auth which is only supposed to affect
regular users, hence it comes after:

account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet

crond requires system-auth for its account check. cron jobs scheduled for
nocpulse do not run because the nocpulse user does not pass the user account

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

How reproducible:


Steps to Reproduce:
1. Install Satellite 410
Actual results:

Users created with uids >= 500

Expected results:

Users created with uids < 500 (ie, useradd -r)
Comment 1 Robin Norwood 2006-09-24 12:25:39 EDT
assigning to rhn415-triage for review by the release team, and re-assigned to
Comment 2 Mike McCune 2006-09-28 20:15:25 EDT
will attempt to fix this in 415
Comment 3 Mike McCune 2006-09-28 20:56:51 EDT

I found where to fix this in our code but I wanted to get more info on how to
setup a system to reproduce the failure so I could ensure that the changes I
make don't break any existing infrastructure.  I'm not familar with system-auth
so I could use some info.

When we create the users (in the NPusers rpm) we are specifically setting the
UID to 502:

/usr/sbin/useradd -c 'NOCpulse user' -u 502 $wheel_group nocpulse
/usr/sbin/useradd -c "NOCpulse Ops" $wheel_group nocops

The engineers who built this RPM aren't around anymore so I don't know the
history around why it was specifically hard coded to 502.  
Comment 4 Mike McCune 2006-09-28 20:57:33 EDT
Feel free to contact me on irc, #rhn or email or this BZ.   Doesn't matter to me.
Comment 5 Mike McCune 2006-10-02 15:34:39 EDT
gotta move this to 420, no time left in this upcoming release to fix this.
Comment 6 Matthew Booth 2007-06-17 18:12:56 EDT
If you stick the above line in /etc/pam.d/system-auth, it should do the trick
for you.

I expect they hardcoded it to 502 because on their development systems, uids for
regular users started at 500. Somebody created a regular user at some point for
nocpulse and nocops and it got assigned 502, then they stuck with it.
Comment 7 Miroslav Suchý 2009-09-11 07:33:54 EDT
Duplicate of 202614
User nocops is not needed anymore.
User nocpulse is now system account with home in /var/lib/nocpulse/

*** This bug has been marked as a duplicate of bug 202614 ***

Note You need to log in before you can comment on or make changes to this bug.