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): How reproducible: Always 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 65536). Expected Results: Commands should have been attributed to the correct user. Additional info:
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. ***
Adding Cc's... 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: CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y 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.