8

User has write-only permissions on a file, unable to cat or vi but is able to nano normally. How is this possible?

I was wondering what happens if you only have write-access on a file and this was how I tested it.

# cd /home/tester
# cat hello.txt
Hello World!
# ls -l hello.txt
-rw------- 1 root root 13 Nov 17 01:55 hello.txt
# chmod o+w hello.txt
# ls -l hello.txt
-rw-----w- 1 root root 13 Nov 17 01:55 hello.txt
# su tester
$ cd ~
$ cat hello.txt
cat: hello.txt: Permission denied
$ nano hello.txt

For some reason, nano is able to read the file (see screenshot). I've confirmed vi is not. My original hypothesis is that having write only permission allows you to only append the file like echo "Hello" > hello.txt.

(See this screenshot for the actual commands I ran.)

Update

ls -l "$(type -p nano)" shows permissions -rwsr-xr-x root root.

Improve this question
  • # suggests you are still root. Are you sure you're tester? Can you do whoami right before you use nano? – user147505 Nov 16 '19 at 9:35
  • @Tomasz I've done whoami and checked that I'm tester. I didn't know realise that # actually meant something. Thought it just meant commands. Its $ from su onwards – ministic2001 Nov 16 '19 at 9:38
  • 2
    Make sure nano was not open before you changed the permissions (are you using it in the same terminal?) and check if your nano is not unexpectedly suid set: ls -l "$(type -p nano)". – user147505 Nov 16 '19 at 10:37
  • -rwsr-xr-x root root is the output when I ran this command as trader03/tester. So I assume thats what u meant by suid set, which is the "s" in user? – ministic2001 Nov 16 '19 at 10:40
  • 4
    Yes. It is suid. This means whoever runs nano, the process has root privileges. This is not expected and shouldn't be happening in any normal environment. Find out with your administrator what the point is. – user147505 Nov 16 '19 at 10:44
10

-rwsr-xr-x root root in the result of ls -l "$(type -p nano)" means it is setuid. As a result, whoever runs nano has root privileges. This is not expected and shouldn't be happening in any normal environment. Find out with your administrator what the point is.

Improve this answer
  • Thanks for the answer! Just one more question. If I were to attempt to remediate this, would it be just chmod u+x /usr/bin/nano ? – ministic2001 Nov 16 '19 at 10:53
  • 1
    @ministic2001 chmod u-s should do. They're two unrelated things formally, so +s doesn't cause +x. – user147505 Nov 16 '19 at 11:00
  • 2
    Good catch @Tomasz. I think that’s actually a bad security hole, as anyone who can execute nano can view and (worse) edit any given file on the server. Probably even shell out as root. Tread carefully and absolutely inform the sysadmin. – bxm Nov 16 '19 at 13:36
  • 1
    The user may want to check if there are other executables in the same directory that shouldn't be setuid (some possibly should be). It might have been a lazy operator who just changed all of them "for convenience". – Kusalananda♦ Nov 16 '19 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.