I'm trying to figure out a quick & easy way to see a list of everyone's effective user id... I would have thought 'w' or 'who' would be able to display if someone had switched user accounts... but it's only showing the real user ID they logged in with.
3 Answers
One approach could be to apply the fuser
command to the pseudo-terminal devices in /dev/pts
, e.g. sudo fuser -v /dev/pts/*
.
As an example, I logged into a Linux system as user1
and ran sudo su user2
, then logged in again (as user1
) via another terminal. After running sudo fuser -v /dev/pts/*
, I got the following output:
USER PID ACCESS COMMAND
/dev/pts/0: user1 5533 F.... bash
root 6291 F.... sudo
/dev/pts/1: user1 5655 F.... bash
root 5748 F.... sudo
root 5752 F.... su
user2 5753 F.... bash
Looking at the second block of output here (corresponding to /dev/pts/1
), you can see that user1
has switched to user2
. For more information on this approach, you may want to consult the following post: How can we know who's at the other end of a pseudo-terminal device?

- 9,886
The logins will show up in the /var/log/secure file (red hat\centos) or /var/log/auth.log (debian\ubuntu), and the format for a login contains the line text "session opened for", so cat /var/log/(secure OR auth.log) | grep "session opened for"
should provide a list of logins like this:
Jan 9 07:07:07 hostname su:pam_unix(su:session): session opened for user user1 by user2(uid=2000)
ps aux | grep username
should list shells running under "username," which is a quick way to check for "username" activity, and very eye-catching if you don't expect to find any "username" activity. This won't tell you WHO logged in as "username" though, so the log files would still need to be consulted for that.
For a large number of users these checks could get cumbersome, I hoped there was something like ps -eo ruid,euid
for just users instead of all processes, but I found nothing that straightforward.

- 404
-
procstat
-a -s -h | awk '{ if (!x[$3]++) print $3; if (!x[$4]++) print $4; }'
– JdeBP Mar 10 '19 at 10:19
Investigative Solution:
I came across this issue trying to determine who was hammering a server through a service account.
By sudo
'ing into the service account and then checking the ~/.ssh/authorized_keys
I was able to identify the user to have a chat with them about their use.
Anyhoo, this is how I solved the problem and it worked...

- 2,476
sudo
creates logs, but ensure that the logs are stored off device, and are only appendable, and readable (not truncatable, deletable), from this device. So a compromised root can to change the logs. – ctrl-alt-delor Mar 09 '19 at 18:50