Lab 18.2 - on ubuntu 14.04.5 setuid doesn't change the result

mladenovicp

After setuid bit on writeit compiled program, if I execute it again as normal user it still doesn't work, it returns

wrote -1 bytes

saqman2060

I tried that lab on my ubuntu 14.04 production latop. I can confirm I cannot modify the "afile" as the normal user. I tried different ways of modifying. even compiling the program as root. Nothing seems to be working.

My guess is that, the own of the program is non-root. So setting the setuid will not have any effect. Changing the owner of the program to root still does not have any effect because you still need to issue "sudo" before running it. We might be using the wrong flag.

saqman2060

I did some testing on my CentOS 6.8 virtual machine and I descovered something interesting. 

When I compiled the writeit program, I compiled it as a non-root user. After creating the "afile" as root, I cannot modify the file even after I set the user-ID. 

I deleted the writeit program and compiled it as root. Then I set the user-ID to "s". Ran the program as a regular user and was able to modify the program.

Here is why

chmod changes user and group access permissions of a file, directory or program. By using the "s" bit, we are telling a program to run as if it had the rights of the user who owns it. Well, writeit was owned by a non-root user, it cannot do anything without permission from root. Setting the user-ID to "s" will not make a program owned by a non-root user execute with root privilages.

When I compiled the program as "root", root became the owner. By using

sudo chmod u+s / or / sudo chmod a+s writeit

I was telling the program to execute with the owner's(root) privilages. In otherwords, whatever user executes writeit, the program will run as if ROOT was running it. By doing it this was, I was able to modify the file.

The lab does not mention these particular setback. We cannot modify files own by root using programs own by non-root users.

luisviveropena

Hi,

Mabe man setuid(2) is not clear enough about it, but Wikipedia is:

setuid and setgid (short for "set user ID upon execution" and "set group ID upon execution", respectively)[1] are Linux access rights flags that allow users to run an executable with the permissions of the executable's owner or group respectively and to change behaviour in directories. They are often used to allow users on a computer system to run programs with temporarily elevated privileges in order to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.

(I replaced Unix by Linux)

So, it's expected that the program will run with the permissions of the owner (user or group). We may haven't mentioned it, but it's supposed to work that way. I think it was a good exercise anyway, because you found and understood how it works.

Regards,

Luis.