Bug 82884 - enable pidentd to bind to only the loopback adapter.
enable pidentd to bind to only the loopback adapter.
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: pidentd (Show other bugs)
8.0
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Eido Inoue
Jay Turner
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-27 22:26 EST by jerry asher
Modified: 2015-01-07 19:03 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-07-28 16:59:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jerry asher 2003-01-27 22:26:48 EST
I would like to be able to tell pidentd to bind only to the loopback adapter. 
Right now, the code is such that it binds to all IN_ANY, all adapters.  That's
not good for security information -- for instance, postgres would like to be
able to use identd to authorize even local users.  So I would like to run
pidentd on the loopback and disallow any information leaking through any other
adapter.
Comment 1 jerry asher 2003-01-27 23:30:24 EST
It would be nice/better to be able to run identd from xinetd.

In general it would be a good documentation feature to explain the difference
between xinetd and sysv init style daemon startups AS WELL AS explain the
process of converting an application/service from one to the other.
Comment 2 jerry asher 2003-02-07 16:06:01 EST
Ya know, I'd would be interested in working on this, and in fact, I tried to
track the author down.  

But I have received no word back from the author, and the mailing list addresses
bounce as well.

Do you know what the status of pidentd is and where development is taking place?
Comment 3 Eido Inoue 2003-07-28 16:59:19 EDT
i'm moving this to UPSTREAM. Any install other than "no firewall" will block
access to the auth (113) port anyway, so as a workaround, the original bug
sumitter should get the level of protection he/she wants.

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