Bug 111640 - RHEL3 U3: pidentd is missing from RHES3
Summary: RHEL3 U3: pidentd is missing from RHES3
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: distribution (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: dff
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-07 14:32 UTC by Bernd Bartmann
Modified: 2007-11-30 22:06 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-02 05:02:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2004:363 normal SHIPPED_LIVE New authd package available 2004-09-02 04:00:00 UTC

Description Bernd Bartmann 2003-12-07 14:32:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
pidentd is missing from RHES3

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

How reproducible:

Steps to Reproduce:
1. where is pidentd?

Additional info:

Comment 1 agt 2003-12-16 23:32:07 UTC
I see this on AS and WS as well - no pidentd packages.

Comment 2 Eido Inoue 2003-12-17 16:56:54 UTC
changing package

Comment 3 Eido Inoue 2003-12-17 17:30:56 UTC
changing yet again

Comment 4 Thierry Linder 2004-02-10 14:39:44 UTC
Thanks to inform me when the pidentd package is available under RH WS 

Comment 5 Larry Troan 2004-04-12 12:13:41 UTC
Issue Tracker 36998 opened as sev 3 by ltroan@redhat.com

Comment 6 Larry Troan 2004-04-12 12:22:41 UTC
From http://freshmeat.net/projects/pidentd/ regarding pidentd:

Pidentd v3 is a much improved version of the original Ident daemon
both in terms of speed, code quality and features. Features include
multithreading, a "configure" script, startup autodetection, much
clearer/rewritten C code, doesn't run as root after startup, has a
configuration file and can be started from /etc/inittab (on systems
using a SysV init).

Adrian, does version 3 solve the security problem that caused pidentd
to be pulled from the RHEL3 package list?

Comment 8 Larry Troan 2004-04-12 12:36:38 UTC
Bernd, agt, Thierry, Rick,
Could one of you PLEASE provide me with a business justiification as
to why this package should be added back into RHEL3 (makes it a lot
easier for me when approaching RH management). 

For example, from the pidentd home page:
This is a program that implements the RFC1413 identification server.
It was very much inspired by Dan Bernstein's original 'authd' (but
unlike that program doesn't use 'netstat' to get some of the
information) It uses the kernel information directly. (And is due to
that fact a lot faster). Dan has now written another version of the
'authd' daemon that uses his 'kstuff' to read the kernel information.
Unlike that daemon, this will use only normally available kernel
access functions (and is due to that more limited in the different
machines it support). Please note that this daemon used to be called
pauthd but has changed name to better reflect what it does (and to
conform to the new RFC).

NOTE THAT pidentd-3.0.16-1 IS INCLUDED IN THE Fedora core1 DISTRIBUTION...

Comment 10 Larry Troan 2004-04-12 15:22:52 UTC
Adrian, Donald,
Customer is asking what security exposure caused us to remove the
package from RHEL3. Can you help me with the specifics?

My guess would be that the latest pidentd doesn't run as root after
startup as it did before. Also, this new package only uses normally
available kernel access functions.

Comment 11 Eido Inoue 2004-04-12 16:19:56 UTC
I was not made aware of any security problems regarding the current
pidentd... other than the implied privacy and information gleening
that could be obtained by running pidentd in a non-crypt way.

If pidentd is missing from a RHEL3 distro then the component should be
changed to "distribution", as the reason it's missing is not due to
pidentd, but do to its intentional/non-intentional ommission from comps.

Comment 12 Larry Troan 2004-04-12 19:41:03 UTC
The person commenting this was a security exposure was referring to
the fact that anyone can query the ident db and find out every process
running on the system. This would give a hacker the ability to focus
on what cracking mechanisms he/she intended to employ.... making it
easier to find holes.   

Comment 13 Eido Inoue 2004-04-12 20:02:47 UTC
Comment 12: in the default configuration, the public reply that
pidentd returns is encrypted; the information can only be decrypted by
the sysadmin that has access to the pidentd daemon. You'd have to
intentionally change the configuration to provide a non-secure version.

Thus, in the default distributed configuration, it isn't possible for
random people to gleen process information. (well, they RECEIVE the
process information, but it's encrypted-- thus the security of pident
rests on the strength and security of the encryption-- of which there
haven't been any known problems)

Comment 24 Jay Turner 2004-09-02 05:02:55 UTC
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.


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