The portmapper object has a dereg()
method that undoes
a reg() - deregisters a specific port or ports with
the portmapper daemon, while keeping any other registered ports.
reg(), dereg(), and
connect() methods also take an additional optional
parameter, a
terminator file descriptor. If the
terminator file descriptor becomes readable, an exception gets thrown,
and the connection to the portmapper daemon is closed, all registered
ports get deregistered.
On Linux, the
/proc/
symlink gives the
name of the executable that started the process.
On Linux, reading a process's executable pathname succeeds
only if both processes have the same userid.
The portmapper provides a way for cooperating processes to make
their executable's name visible to other processes.
pid/exe
The third parameter
to reg() is a set of bitwise-or flags one of which
is x::httportmap::base::pm_public. If set, the
process's executable pathname gets included as part of the registered
service.
A low-level portmapper method, list(), returns a list
of services registered with the portmapper, include the executable
pathname, if made public.
This is the low-level approach. The high level approach uses
regpid2exe():
#include <x/httportmap.H> x::httportmap portmapper(x::httportmap::create()); portmapper->regpid2exe(); // ... pid_t pid; // ... std::string path=portmapper->pid2exe(pid);
regpid2exe() advertises this process's executable
pathname through the portmapper. pid2exe() returns
another process's executable pathname, if the other process
called regpid2exe() previously. An empty string gets
returned if the process could not be found, or did not call
regpid2exe().
There's also a deregpid2exe() that deregisters the
reserved service that announces the executable pathname.
Like other portmapper methods, these three functions also take an optional
timeout file descriptor parameter; although that since they always connect
to a portmapper instance running on the same machine, the timeout file
descriptor offers little practical purpose.
regpid2exe() counts towards the limit on the
maximum number of registered services, with the portmapper,
from the same process.
Advertised executable pathnames are considered to be supplementary metadata, and should not be exclusively relied upon, for authentication. For example, after reading an executable's process id, the original process can fork, with the parent exiting, and subsequently the process id gets recycled for another process. When a process creates a connection with the portmapper, if the portmapper has a registered entry ostensibly from the same process id, but a different executable name, the portmapper removes the other process's executable name.
Announcing and advertising a pathname provides a means for identifying and connecting to applications. In situations that involve some kind of authentication, it should be done by other means, like sending userid/groupid credentials over filesystem domain sockets.
If a process's executable binary gets deleted, but the process still runs, its executable pathname no longer exists. Long-running server daemons should connect to the portmapper and advertise their pathname promptly after starting, on systems that use prelink, which tends to overwrite binaries, periodically.