Bug 82884 - enable pidentd to bind to only the loopback adapter.
Summary: enable pidentd to bind to only the loopback adapter.
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pidentd (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
low
medium
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: Jay Turner
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-28 03:26 UTC by jerry asher
Modified: 2015-01-08 00:03 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description jerry asher 2003-01-28 03:26:48 UTC
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-28 04:30:24 UTC
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 21:06:01 UTC
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 20:59:19 UTC
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.