A colleague sets root ownership and the set-UID bit on a bash script so that ordinary users can run it with root privileges. Users run it and still get permission denied on the privileged step. Why?
LPIC-1 Exam 102-500, objective 105. Shells and shell scripting hard
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Correct Linux ignores the set-UID bit on files executed through an interpreter line, so the script runs with the caller's own privileges
Correct. The kernel deliberately does not honour set-UID on scripts started via a #! interpreter, because of unfixable race conditions between the permission check and the interpreter opening the file.
Not correct The set-UID bit takes effect only after the script is also given the sticky bit
Wrong. The sticky bit on a directory restricts who may delete files in it; on a regular file it has no bearing on privileges at all.
Not correct chmod refuses to set the set-UID bit on a text file, so the bit was never stored
Wrong. chmod u+s sets the bit on any regular file the caller owns, and ls -l duly shows the s. The bit is present; the kernel simply disregards it here.
Not correct The script must additionally be owned by the group root for the bit to apply
Wrong. Group ownership is what the set-GID bit concerns. The set-UID bit is about the owning user, and the file is already owned by root.
Why
On Linux, execve honours set-UID and set-GID only for binary executables; for a file with a #! line the kernel runs the named interpreter, and the privilege bits are dropped. That is why the supported way to grant a script elevated rights is a sudo rule naming the script's absolute path, or a small compiled wrapper. Setting the bit is not merely ineffective, it is misleading, since it suggests a privilege boundary that does not exist.
Where this comes from
- Cited
- manual page execve(2)
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 105 and space the ones you get wrong.
More questions on this objective
- A user logs in at a text console, and bash starts as an interactive login shell. Which file in that user's home directory is read by bash itself as part of login startup? machine-checked
- You are already logged in to a graphical desktop and open a new terminal window, so bash starts as an interactive shell that is not a login shell. Which per-user file does bash read in that case? machine-checked
- An executable script contains only the line `export EDITOR=vim`. After running it as `./setenv.sh`, `echo $EDITOR` in the calling shell prints nothing. What explains this? machine-checked
- In bash, what is the effect of `export MYVAR`? machine-checked
- At a bash prompt you run `alias ll='ls -l'` and it works for the rest of that session, but a terminal window opened afterwards does not recognise `ll`. Which statement explains this and gives the standard remedy? machine-checked
- A command finishes and the shell reports an exit status of 0. What does that mean, and which parameter reports it? machine-checked