These features are enabled by default. To disable communication with the identd, use the -I flag.
If you are runnig Tircproxy for more than one user, you will probably want it to cooperate with the ident daemon on your system for reasons described in the Tircproxy feature overview and the chapter about IRC basics.
This section does not cover the configuration or installation of the identd itself, but describes the different methods used for communication and how they are configured.
Two issues are involved - the configuration of Tircproxy's user list (who owns what IP address), and the mechanism used by Tircproxy to communicate with the local ident daemon. The user list is primarily used to determine what is sent to the identd, but it can also be used for access control, as described in the TCP wrapper compatibility chapter.
This is the preferred way to cooperate with ident daemons and configure
the user list. If the UDB libraries are present on your system at compile
time, support for this feature will be built in and enabled by default. It
can be manually disabled by editing tircproxy.h
before compiling.
Shared memory configuration requires that UDB support be compiled into the proxy, and it's a good idea to UDB administration tools installed as well. If the local ident server is also UDB-aware (see the UDB home page for a list) the shared memory tables will automatically be used for communication between the two programs. This is ideal, since it does not require Tircproxy to run with root-privaleges (thus avoiding many potential security issues), consumes very few resources and is quite fast.
UDB provides a persistant shared-memory database of user information, including information mapping users to IP addresses, and users to TCP/IP connections (such as those made by Tircproxy). Thus UDB can be used by Tircproxy to both aquire information about who is using it (by mapping IPs to user names), and pass this information on to a a local UDB-enabled ident daemon (by mapping IRC connections to user names).
Users may be divided into two groups, depending on how they are configured - static users (users who always have the same IP address) and dynamic users. The more interesting case involves dynamic users. Since their address changes each time, you will somehow need to add each user and his IP address to the database when he connects, and remove the data when he disconnects. How to do this depends entirely on your environment - but a couple of common cases are covered in the following sections, followed by a brief discussion of how to handle static users.
Linux: dynamic PPP dial-in users
When a PPP session is initiated on a Linux box, the Linux PPP daemon will
run a script named /etc/ppp/ip-up
. When they disconnect, it will
run a script named /etc/ppp/ip-down
. You can use these scripts,
and the tools included with UDB, to record these changes. Simply add the
following command to /etc/ppp/ip-up
:
udb_ipuser $5 $LOGNAME ppp
And the following to /etc/ppp/ip-down
:
udb_rm ip ip $5
(Note that on recent RedHat Linux systems (and possibly others), you should
alter the files /etc/ppp/ip-up.local
and
/etc/ppp/ip-down.local
, instead of the files named above.)
Dynamic users, authenticated using RADIUS
At many ISPs, RADIUS servers are used to authenticate users dialing into specialized dial-in boxes (e.g. from Cisco or Cyclades).
At the moment no RADIUS server supports UDB, but support by the FreeRADIUS server is in the works.
Static users
The static users may simply be configured at system start-up time, since the
UDB database is never deleted. This would probably be done either by
creating a custom initialization script containing udb_ipuser
commands like those described above, or by using the startup script included
in the UDB distribution, and adding users to the /etc/udb.conf
file.
Problems to avoid
People unfamiliar with System V shared memory may run into problems using UDB for configuration and/or communication, since the same type of user and group permissions apply to shared memory segments as to files in the filesystem. If the Tircproxy user doesn't have permission to write to the shared memory tables, or the ident daemon cannot read them, then communication will fail. If the Tircproxy user cannot read the tables, then the user information they contain will have no effect.
See the UDB documentation for details about how to use and/or troubleshoot UDB-aware applications (such as Tircproxy) effectively.
The alternative to shared-memory based identd support, is to use the filesystem. This method is slow and prone to race conditions, because it relies on files being created or deleted relatively quickly when dynamic users log on or off (user list configuration) or when new connections are established (identd communication). For these reasons (and others), the filesystem method is discouraged - people should use the UDB shared memory strategy if at all possible. By default this feature is built into the proxy at compile time, if (and only if) the UDB libraries are unavailable.
In spite of the drawbacks, the filesystem method usually works reasonably well and like the shared memory method it can allow Tircproxy to communicate with an ident daemon without running as root.
Assigning an IP address to a given user is accomplished by creating a text
file name user-<ip address>
containin nothing but the
username on the first line.
Where to put this file depends on whether you have oidentd support built in
or not. If oidentd support is built in, the default location is
/var/oidentd/
, but without it the default is /var/run/
.
Both values may be altered at compile time by editing tircproxy.h
.
Configuring a static user (e.g. for IP 10.11.12.13) is as simple as this:
echo username > /var/oidentd/user-10.11.12.13
Dynamic users could be handled by adding similaur commands to scripts or logon systems (such as RADIUS).
A patched version of oidentd 1.4 was the only ident daemon able to
communicate with Tircproxy using the filesystem. The necessary patches and
a copy if the daemon are available on
the Tircproxy home page. The modified oidentd
daemon will check /var/oidentd/
for files mapping individual TCP/IP
connections to usernames, which are automatically created by Tircproxy if
this feature is enabled.
This feature is enabled by default, if (and only if) the proxy is run as root. Disable it by specifying a non-root user (e.g. "nobody") on the command line, with the -r username arguement, or by directly running the proxy as a normal user.
If neither shared memory or filesystem based communication is desired (e.g.
because it is not supported by your identd), the last resort to guarantee
correct identification is to make the proxy actually assume the identity of
the user it is working for. This requires that each user of the proxy have
an account on the system (an entry in /etc/passwd
), and that either
the filesystem or UDB tables map all client IPs to such usernames.
If the client's IP address isn't found in the proxy user list, the connection will be rejected, unless the -R flag (relaxed mode) is present on the command line. Relaxed mode is not recommended on systems with standard ident daemons, because it can both reveal that the proxy is running as root (thus encouraging attackers to try to hack the proxy) and cause different users to recieve the same identification (root).
Please note that running Tircproxy as root (especially in relaxed mode) is discouraged, because of the security risks involved: flaws in Tircproxy could expose your system to root compromise by outsiders - the worst kind of security hole on Unix-like systems. You have been warned!