Bug 426745 - Default RH ntpd startup script makes ntpd not drop its root GID
Summary: Default RH ntpd startup script makes ntpd not drop its root GID
Status: CLOSED DUPLICATE of bug 426761
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ntp   
(Show other bugs)
Version: 4.6
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-12-25 19:04 UTC by David Tonhofer
Modified: 2008-01-24 15:27 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-24 11:06:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Tonhofer 2007-12-25 19:04:00 UTC
Description of problem:

The default "/etc/sysconfig/ntpd" file contains:

# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"

The string "ntp:ntp" is uselessly overspecifying the user's group.

Anything beyond the ":" is filtered away by RHES /etc/rc.d/init.d/ntpd script
and the manpage of ntpd indicates that the ntpd daemon will drop to the user's
primary group. Thus I suggest just writing

# Drop root to id 'ntp' by default.
OPTIONS="-u ntp -p /var/run/ntpd.pid"

Comment 1 Miroslav Lichvar 2008-01-02 14:51:24 UTC
With "-u ntp" ntpd will change user ID, but not group ID. The man page needs to
be fixed instead.

Comment 2 David Tonhofer 2008-01-02 18:20:30 UTC
"The man page needs to be fixed instead."

Indeed! I am somewhat amazed:

# ps -o command,euid,egid,ruid,rgid 11632

ntpd -u ntp -p /    38     0    38     0

Shouldn't this be, like, fixed as a security-related problem with the RH4.6 ntpd?

I just looked for some additional details and found this:



The manpage of ntpd delivered with RH ES4.6 is too old. The real manpage gives
it away:


-u user[:group]

    Specify a user, and optionally a group, to switch to. This option is only
    available if the OS supports to run the server without full root privileges.
    Currently, this option is supported under NetBSD (configure with
    --enable-clockctl) and Linux (configure with --enable-linuxcaps).

So, if one changes the RH /etc/rc.d/init.d/ntpd script to NOT filter
out the ":gid" in "-u uid:gid"

and if one leaves "/etc/sysconfig/ntpd" file at the delivered default:

# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"


# ps -o command,euid,egid,ruid,rgid 12919
ntpd -u ntp:ntp     38    38    38    38

Setting urgency to "high"...

Comment 3 Miroslav Lichvar 2008-01-24 11:06:33 UTC
Closing as duplicate of another bug that needs updating man pages from html.

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

Comment 4 David Tonhofer 2008-01-24 13:31:12 UTC
Hi, Original Reporter here.

This bug is actually not a duplicate of #426761. 

#426761 says "the man pages must be updated"

This bug exposes a problem (rendered more confusing because the man pages are
out of date) whereby the GID of the ntpd daemon is not dropped from "root" because:

1) The delivered ntpd.sysconfig contains "-u ntp:ntp"
2) The delivered ntpd.init erases the ":ntp" in that string in "readconf()",
yielding "-u ntpd"
3) which means that ntpd runs with GID "root" as only -u ntpd:ntpd would drop
the GID in additiona to the UID

(This needs confirmation from an untouched RHES4.6 system; I do not have that on

Changing the title of the bug from 

"The "-u" option in "/etc/sysconfig/ntpd" contains useless group name"


"Default RH ntpd startup script makes ntpd not drop its root GID"

Comment 5 Miroslav Lichvar 2008-01-24 13:54:09 UTC
No, ntpd in default configuration with default init script drops root GID.

The $dropstr variable containing "-U ntp" is used only for ntpdate which doesn't
accept group specification, but changes GID to the primary group of the
specified user.

Comment 6 David Tonhofer 2008-01-24 15:27:31 UTC
Oh yes, I see. So there is no problem. 

This is all pretty confusing; needs more comments ;-)

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