Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 82884 - enable pidentd to bind to only the loopback adapter.
Summary: enable pidentd to bind to only the loopback adapter.
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pidentd
Version: 8.0
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: Jay Turner
URL:
Whiteboard:
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:
Clone Of:
Environment:
Last Closed: 2003-07-28 20:59:19 UTC


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.