Red Hat Bugzilla – Bug 62481
lastcomm uses 16-bit UIDs
Last modified: 2007-11-30 17:10:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u)
Description of problem:
lastcomm uses 16-bits UIDs, while the rest of the system now supports 32-bit
UIDs. This could be a security issue if the lowest 16 bits of a UID match the
UID of another user (for example, UID 65536 or 131072 would show up as root).
If both users with "equivalent" UIDs are logged in, there is no way to tell who
ran which commands.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a user with a high UID (65536 or greater)
2. Make sure accounting is on
3. login as the newly created user
4. Run some commands
5. Become root
6. Run lastcomm
Actual Results: Commands run by the user show up as having been run by (UID mod
Expected Results: Commands should have been attributed to the correct user.
Believe it or not, this is actually not a bug. It is really the lack of
the kernel process accounting code being 32bit UID aware. In other words,
the kernel's accounting code is purely 16bit UID/GID, among other problems.
Fixing this, requires fixing it in the kernel first, and then in the
userland utilities. Doing so however may break binary compatibility,
and so a full fix may have to wait for Linux 2.5.x development
cycle, which will become official in 2.6.0.
I will have a look into implementing support in a compatible way however
in the meantime.
Created attachment 51686 [details]
Kernel patch to provide 32bit UID/GID support, and also fix highuid bug
*** Bug 56829 has been marked as a duplicate of this bug. ***
Working on userland support...
I've implemented support for the userland tools but have not put it into
our packaging yet, because I'd like to test it fully first. Once that
is done, I will probably release it as an enhancment release.
I finally got around to testing this code, after the patch appeared in the kernel
which shipped with redhat 7.3. I was disappointed however, to see that the
psacct package had not been patched. I made a couple of fixes to lastcomm.c
and sa.c (changing ac_uid to ac_uid32 in a few places), then patched
/usr/include/linux/acct.h and /usr/include/sys/acct.h in the same way that you
patched the kernel source. 32-bit accounting now works wonderfully on my system.
I can submit the patches if you like.
Still broken in the Limbo public beta
ag381597) You can't just replace those variables like that or you will
break compatibility. It will work with our kernel and nobody elses.
This was not fixable without upstream changes to the kernel.
The 2.6 kernel now has support for 32-bit uid/gid in the accounting code
which is enabled by setting:
The userspace tools are being modified to support the V3 data format.
This bug will be used to track these changes against Fedora Core 3.
*** This bug has been marked as a duplicate of 131757 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.