- be safe with unlinking files (from freebsd)
- remove register
- clean up $NetBSD$'s.
- use inet_ntoa() in one place (from openbsd)
- nul terminate after a bunch of strncpy()'s
- #ifdef __STDC__ rather than #if (from freebsd)
- be safe with a bunch of string operations (from freebsd)
- use warn()/err() over home grown versions (some from freebsd)
- rename warn() to nodaemon() to remove conflict with above
- check errno from failed kill(2) against ESRCH (from freebsd)
- use getopt() rather than home grown versions (from freebsd)
- clean up a bunch of man pages (some from freebsd)
- check for hostname spoof (from freebsd)
- use POSIX wait() interfaces
- use sysconf(_SC_OPEN_MAX) in preference to NOFILE (from freebsd)
- deal with fork() failure
- index/rindex -> strchr/strrchr (some from freebsd)
- add B57600 and B115200 speeds (from freebsd)
- some KNF
- be safe with files passed in over the network (some from freebsd)
- check return value of malloc(), calloc() and strdup()
(1) incorrect check on length of data being written (fix provided by
Paul Sijben <Paul.Sijben@huygens.org>), and
(2) inadequate buffer (too small) for data being sent to remote meant
that properly-formed messages couldn't be created, so job removal
didn't work properly.
(1.2 release is, however, and this should be pulled up and released ASAP)
The previous version (1.11) checked into current limits the duration of
setuid-root periods much more than the 1.2 released version does, so the
attacker DID get a shell, but it was not a root shell.
lpd run in a mode where the it listens only to the local unix domain
socket and not to the network. Changes are similar but not identical
to the supplied patches.
The problem here is setuid(euid) is used far too much. Since I removed
many of these calls, and added no new ones, I do not think this weakens
security. In fact, it quite likely improves it quite a bit, since
access() is called as the real userid, and the file is opened for printing
as the real userid rather than the (setuid-root) effective one.
there are some PC/Mac oriented devices that use non-standard speeds,
furthermore that's just not the way we do things anymore.
"Bad" baud rates are no longer caught with their own error message,
but the condition will still be diagnosed when the tcsetattr() fails.
christos