sudo state detection is working incorrectly

[Roang-zero1]

The detection of the sudo state of the current terminal is not working as I would think it works from the description.
The current implementation at

powerlevel10k/internal/p10k.zsh

Lines 1479 to 1490 in dfc98ad

	local state
	if (( P9K_SSH )); then
	if [[ -n "$SUDO_COMMAND" ]]; then
	state="REMOTE_SUDO"
	else
	state="REMOTE"
	fi
	elif [[ -n "$SUDO_COMMAND" ]]; then
	state="SUDO"
	else
	state="DEFAULT"
	fi

only shows the sudo state if the shell has been started within a sudo environment that is not a root user.
It doesn't show when a sudo command without password promt is possible.

More details in the related bug in Powerline9k at:

• Sudo state in user segment working under strange circumstances only Powerlevel9k/powerlevel9k#1083
• Use SUDO_COMMAND to check for sudo Powerlevel9k/powerlevel9k#937 (comment)
• About sudo detection Powerlevel9k/powerlevel9k#852

[romkatv]

SUDO state in p9k is meaningless. It's also meaningless in p10k.

The detection of the sudo state of the current terminal is not working as I would think it works from the description.

Which description?

[Roang-zero1]

Sorry I meant the description from the powerlevel9k segment.
Which states:

State	Meaning
SUDO	You are using elevated rights
REMOTE_SUDO	You are SSH'ed into the machine and have elevated rights

[romkatv]

That description makes no sense though. "You are using elevated rights" is ROOT state.

Could you tell me what you want to achieve?

[romkatv]

Powerlevel9k docs also have this sentence:

SUDO and REMOTE_SUDO states are also available to show whether the current user or remote user has superuser privileges.

This also makes no sense. Here's how it actually works:

1. (Both in 9k and 10k) If you have privileges, context segment is in state ROOT.
2. (Only 10k) If you are connected over ssh, P9K_SSH is 1.

SUDO and REMOTE_SUDO have the same meaning as DEFAULT. I keep these states for backward compatibility but they really have no meaning distinct from DEFAULT.

[Roang-zero1]

I will focus on LOCAL as the REMOTE context is the same just for SSH connection:
My understanding of the states would be the following:

State	Meaning	Function
DEFAULT	You are a normal user	You are a normal user; If you try to use a command such as sudo vi <file> you would be promted for a password
ROOT	You are the root user	You are in a terminal for the user root
SUDO	You are using elevated rights	You are a normal user; If you try to use a command such as sudo vi <file> the command would be executed as you used sudo before and the terminal is "elevated"

This was the functionality before the changes done in Powerlevel9k/powerlevel9k#937 (but the old functionality had problems with spamming journalctl)

[romkatv]

This was the functionality before

The old implementation was showing sudo if sudo true succeeds without password. It's not the same thing as running from a TTY blessed by sudo. For example, try adding $USER ALL=(ALL) NOPASSWD: /bin/true to sudoers. It won't grant you any real privileges and yet sudo true will succeed without password.

The old implementation had serious issues. If you actually typed sudo cmd and entered your password, powerlevel9k was extending the ticket on every prompt. It was also spamming journal with failed sudo attempts.

AFAIK, there is no portable (or at least not horrible) way to check whether the current TTY is blessed by sudo. If you know how to do this, please share.

[Roang-zero1]

Just some brainstorming I have not tested this method or thought about implementation with zsh/powerlevel10k:

• The sudo rights for a user are stored in /var/run/sudo/ts/<username>.
• This file is eiter readable by the user or root
  -rw------- 1 root <user-group> 168 Apr 3 17:29 /var/run/sudo/ts/<user>
• The format is known https://www.sudo.ws/man/1.8.24/sudoers_timestamp.man.html
• A sample parser in C can be found at https://unix.stackexchange.com/a/332143

So in effect we could parse the timestamp for our user in our tty (ttydev/ppid) and see if he is authenticated as uid 0 (auth_uid). The only thing I am not sure is how to get the timeout for the timestamp.

[romkatv]

Yep, I know how it works.

The location of the database is different in different distros. On my machine it's in /var/run/utmp. On BSDs it also has a different format.

I'm closing this issue if that's OK with you.

[Roang-zero1]

Sure, thanks for going into the details