util-linux / PAM · Event session opened for user root by
su: someone switched to another account successfully
A user became another account, usually root. The line records who did it and when — and then stops. Unlike sudo, which logs every command, su hands over a shell and everything that happens afterwards is attributed to the target account with no further record.
Also written as su to root logsu (to root) session openedsuccessful su root syslog
- How oftenUncommon
- Vendor calls itauth.notice
- Logauth
What it means for you
For an analyst
This is the accountability gap that makes sudo the preferred tool. sudo logs a line per command with the invoking user attached; su logs one line and then nothing, so a root shell obtained this way produces activity indistinguishable from any other root activity. Two practical consequences. First, treat every su-to-root as the start of an unattributable window and note who opened it. Second, if you need coverage inside that window, auditd is the only thing that provides it — the auid stays with the session across the identity change, which is precisely why auditd's auid field is more useful than the euid for this.
The fields that decide it
Everything else in the log line is context.
- Target user
- Who they became. root is the common case and the one worth watching; switching to a service account is often a legitimate deployment step.
- Invoking user
- Who did it, given in the 'by' clause. This is the only attribution you get, and it appears on this line and nowhere afterwards.
- uid values
- The numeric IDs on both sides. A 'by (uid=0)' means root switched to another account, which happens in scripts and produces no accountability question.
- The tty
- Which terminal. A pts device is an interactive session; a missing or unusual tty often means a script rather than a person.
- What follows in the log
- Not a field, but the point of the record. Expect no further trace of this person's actions — that absence is the reason this event matters.
Common questions
Why is su considered worse than sudo for auditing?
Because su logs the moment of the switch and nothing after it. Once someone has a root shell, every command they run is recorded — where it is recorded at all — as root, with no link back to the person. sudo logs each command individually with the invoking user attached, so the trail survives. This is the main reason most organisations disable su in favour of sudo.
How do I find out what someone did after su to root?
Not from syslog. Shell history is unreliable and trivially cleared, and the process accounting that would help is usually not enabled. auditd is the practical answer: it stamps every record with the original login UID, which does not change when the user becomes root, so activity inside that shell remains attributable. Without auditd, the honest answer is that the window is not covered.
Is a successful su to root a security incident?
Not on its own — on many systems it is how administration is done. It becomes one when the invoking user has no reason to need root, when it happens outside working hours from an unexpected session, or when it follows a run of failed attempts. The preceding lines in the auth log usually settle which of those you are looking at.
What is the difference between 'su' and 'su -'?
'su -' starts a login shell, loading the target account's full environment and moving to its home directory, while plain 'su' keeps the current environment. It matters for troubleshooting, because a command that works one way and fails the other is nearly always a PATH or environment difference rather than a permissions problem. Both produce the same session-opened line.
Read next
- The equivalent of Authentication failure: a sudo or su attempt was rejected The failed attempt to switch user, which is what precedes this when someone gets the password wrong first.
- The equivalent of sudo: a command was run as another user sudo, which logs each command with the invoking user rather than handing over an unlogged shell.
- Usually comes after auditd type=SYSCALL: the record everything else hangs off The audit records that do keep attribution across the identity change, via the auid field.
- Usually comes before Accepted password: an SSH login succeeded The login that put the user on the machine before they escalated.
- Read alongside auditd USER_AUTH: an authentication attempt was recorded The audit subsystem's own record of the authentication that allowed the switch.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026