On IRC, a common requirement for connection (or access to certain channels) is to have a valid username. Information about a user's identification is made visible to other users as a username@hostname string, such as bre@ppp-248-123.isp.some.where.com.
The IRC server aquires the username by querying the client machine's ident daemon, if one is running. As Tircproxy will usually be running under some system account on a multi-user Unix machine, this poses a problem for the users of the proxy - they will all be identified as proxyuser@tircproxyhost.
Since this identification is frequently used to grant privaleges to users (or to punish them) sharing a common ID will cause problems.
This is of course not a problem if Tircproxy is run by a single user for personal use only (e.g. as a bouncer).
For others, there are three possible solutions:
In cases 2 and 3, Tircproxy must generate its own psuedo-usernames based on e.g. the IP address of the client, or read information about what user is using a given IP address from configuration files. Tircproxy in it's current incarnation can only map one user-name to each IP address at a time, which may cause problems for users sharing a single multi-user machine which is behind a firewall.
If all users of the proxy have a local username on the proxy host, then Tircproxy can simply change personalities before connecting to the IRC server.
For this to work, Tircproxy will need information about which client IP addresses belong to which users.
This simple solution has one serious drawback though - only processes running as 'root' can change their UIDs. This implies that any mistakes I may have made writing Tircproxy, could be abused to remotely gain administrator capabilities on the proxy host!
To avoid running the proxy as root, and to increase the control Tircproxy has over the replies provided by the system's ident daemon, Tircproxy can communicate directly with modified versions of some ident daemons. Check the Tircproxy home page for a list of available patches.
The first to be patched was the oidentd daemon, which was chosen for use with Tircproxy because it was relatively full-featured, and had recently been audited by members of the Linux Security Audit project.
Again, for this to work optimally, Tircproxy will need information about which client IP addresses belong to which users. Alternately, if no such information is available, Tircproxy can generate 'fake' IDs based on the client's IP address.