[Bug libc/24492] utmp/wtmp locking allows non-privileged user to deny service

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=24492

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
This issue seems to exist on Solaris and AIX as well, although they uses a
different path (/var/run/utmpx for Solaris and /etc/utmp).  As with glibc-based
system, its permission is similar that it allows users to read-lock it:

Solaris:
$ ls -l /var/run/utmpx
-rw-r--r--   1 root     bin         7440 May 14 14:56 /var/run/utmpx

AIX:
$ ls -l /etc/utmp
-rw-r--r--    1 root     system        38232 May 14 08:39 /etc/utmp

The same issue also prevents further login on the system, as sshd for instance. 

I think a better alternative would just to make the utmp file no accessible to
user as default with the side effect of making utmp{x} interfaces return EPERM
as default. I am not sure how it would play on its usage in login process, but
I also don't think using a different lock file while still using default
permission for /var/run/utmp would be an improvement here.  The privileged
process still need to have non-blocked access to utmp regardless and I think
adding a timeout to abort in such cases is also not an option (besides it is
not defined in the standard, it also not expected such functions fail in this
scenario). Another possibility is to route utmp{x} interfaces to a privileged
process.  

Not sure which would be the best option, thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.