libulog now only provides functions that are used by various packages
from the ports tree, namely the libutempter ones. There is no reason to
link it into the crunch/fixit binaries anymore.
It makes hardly any sense to expose a symbol which should only be
provided for binary compatibility, but it seems we don't have a lot of
choice here. There are many autoconf scripts out there that try to
create a binary that links against the old symbol to see whether
uname(3) is present. These scripts fail to detect uname(3) now.
It should be noted that the behaviour we implement is not against the
standards:
| The following shall be declared as a function and may also be defined
| as a macro:
|
| int uname(struct utsname *);
POSIX 2008 and XSI 7require strcoll() for opendir() is not true.
I can't find such requirement in POSIX 2008 and XSI 7.
So, back out that part of my commit, returning old strcmp(), and remove
this misleading comment.
By using random values for ut_id, not based on the TTY name, it is
possible to run for example login(1) multiple times on the same TTY,
without overwriting any previous records.
The output of w(1) will then be as follows:
| 12:26PM up 2 days, 2:31, 5 users, load averages: 0.01, 0.03, 0.03
| USER TTY FROM LOGIN@ IDLE WHAT
| ed pts/2 mekker.80386.nl 12:26PM - w
| root pts/2 - 12:26PM - w
| root pts/2 - 12:26PM - w
| root pts/2 - 12:26PM - w
Approved by: des
It also matches now how our 'ls' works for years.
b) Remove comment expressed 2 fears:
1) One just simple describe how strcoll() works in _any_ context,
not for directories only. Are we plan to remove strcoll() from everything
just because it is little more complex than strcmp()? I doubt, and
directories give nothing different here. Moreover, strcoll() used
in 'ls' for years and nobody complaints yet.
2) Plain wrong statement about undefined strcoll() behaviour. strcoll()
always gives predictable results, falling back to strcmp() on any
trouble, see strcoll(3).
No objections from -current list discussion.
- Massively reduce BSS usage. Let futx_to_utx() dynamically allocate the
structure. There is only a very small amount of applications out there
that needs to use the utmpx database. Wasting 1 KB on unused
structures makes little sense.
- Just let getutxid() search for matching ut_id's for any *PROCESS-type.
This makes the code a bit more future-proof.
- Fix a POSIX-mistake: when reading POSIX and the OpenSolaris
implementation, getutxline() must return USER_PROCESS and
LOGIN_PROCESS records whose ut_lines match. When reading POSIX, it
seems LOGIN_PROCESS should not use ut_line at the first place. I have
reported this issue.
I changed login_tty() to only work when the application is not a session
leader yet. This works fine for applications in the base system, but it
turns out various applications call this function after daemonizing,
which means they already use their own session.
If setsid() fails, just call tcsetsid() on the current session.
tcsetsid() will already perform proper security checks.
Reported by: Oliver Lehmann
MFC after: 1 week
After comparing how other systems deal with utmp/utmpx, I noticed many
systems don't even care about ttyslot(3) anymore, since utmpx doesn't
use TTY slots anyway. We don't provide any tools to access old utmp
files anymore, so there is no use in letting applications write to a
proper offset within the utmp file.
Just let ttyslot(3) always return 0, which seems to be the default
behaviour on operating systems like Linux as well.
Nowadays uname(3) is an inline function around __xuname(3). Prevent
linkage of new binaries against this compatibility function, similar to
what I did with ttyslot(3).
This utility allows users to convert their wtmp databases to the new
format. It makes no sense for users to keep their wtmp log files if they
are unable to view them.
It basically copies ut_line into ut_id as well. This makes it possible
for last(1) and ac(8) to match login records with their corresponding
logout record.
I forgot to cast the size_t's back to off_t before negating them,
causing all sorts of artifacts where the log files would grow to 2^32 -
197 bytes.
Reported by: ume
Even though we use __sym_compat(), we should list the symbol in
Symbol.map.
ttyslot() is now listed as follows, which seems to do the right thing:
| Symbol table '.dynsym' contains 2755 entries:
| Num: Value Size Type Bind Vis Ndx Name
| 613: 00000000000477b0 121 FUNC GLOBAL DEFAULT 10 ttyslot@FBSD_1.0
Reported by: kib
Phase out ttyslot(3).
The ttyslot() function was originally part for SUSv1, marked LEGACY in
SUSv2 and removed later on. This function only makes sense when using
utmp(5), because it was used to determine the offset of the record for
the controlling TTY. It makes little sense to keep it here, because the
new utmpx file format doesn't index based on TTY slots.
The ttyslot() function was originally part for SUSv1, marked LEGACY in
SUSv2 and removed later on. This function only makes sense when using
utmp(5), because it was used to determine the offset of the record for
the controlling TTY. It makes little sense to keep it here, because the
new utmpx file format doesn't index based on TTY slots.
These functions only apply to utmp(5). They cannot be kept intact when
moving towards utmpx. The login(3) function would break, because its
argument is an utmp structure. The logout(3) and logwtmp(3) functions
cannot be used, since they provide a functionality which partially
overlaps.
Increment SHLIB_MAJOR to 9 to indicate the removal.
I'm not increasing the shlib major version for this, because not a
single application outside the base system should have used these
functions in such a short timespan.
Rewrite ulog_login(3) and ulog_logout(3) to build on top of the utmpx
implementation in libc.
The utmpx interface is the standardized interface of the user accounting
database. The standard only defines a subset of the functions that were
present in System V-like systems.
I'd like to highlight some of the traits my implementation has:
- The standard allows the on-disk format to be different than the
in-memory representation (struct utmpx). Most operating systems don't
do this, but we do. This allows us to keep our ABI more stable, while
giving us the opportunity to modify the on-disk format. It also allows
us to use a common file format across different architectures (i.e.
byte ordering).
- Our implementation of pututxline() also updates wtmp and lastlog (now
called utx.log and utx.lastlogin). This means the databases are more
likely to be in sync.
- Care must be taken that our implementation discard any fields that are
not applicable. For example, our DEAD_PROCESS records do not hold a
TTY name. Just a time stamp, a record identifier and a process
identifier. It also guarantees that strings (ut_host, ut_line and
ut_user) are null terminated. ut_id is obviously not null terminated,
because it's not a string.
- The API and its behaviour should be conformant to POSIX, but there may
be things that slightly deviate from the standard. This implementation
uses separate file descriptors when writing to the log files. It also
doesn't use getutxid() to search for a field to overwrite. It uses an
allocation strategy similar to getutxid(), but prevents DEAD_PROCESS
records from accumulating.
Make sure libulog doesn't overwrite the manpages shipped with our C
library. Also keep the symbol list in Symbol.map sorted.
I'll bump __FreeBSD_version later this evening. I first want to convert
everything to <utmpx.h> and get rid of <utmp.h>.
Prior to this commit, fread/fwrite calls with size * nmemb > SIZE_MAX
were handled by reading or writing (size_t)(size * nmemb) bytes; for
example, on 32-bit platforms, fread(ptr, 641, 6700417, f) would read 1
byte and indicate that the requested 6700417 blocks had been read.
This commit adds a check for such integer overflows, and treats them as
if an overly large request was passed to read/write; i.e., it sets errno
to EINVAL, sets the error indicator on the file, and returns a short
object count (0, to be specific).
The overflow check involves an integer division, so as a performance
optimization we check first to see if both size and nmemb are less than
2^16; if they are, no overflow is possible and we avoid the division.
We assume here that size_t is at least 32 bits; this appears to be true
on all platforms FreeBSD supports.
Although this commit fixes an integer overflow, it is not likely to have
any security implications, since any program which would be affected by
this bug fix is quite clearly already very confused.
Reviewed by: kib
MFC after: 1 month
