Next Previous Contents

4.9 Identd support and user configuration

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.

Shared memory based identd support

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.

Filesystem based identd support (depraciated)

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.

Changing user IDs

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!


Next Previous Contents