Re: /proc/pid/fd/ shows strange mode when executed via sudo.

linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

From: Serge Hallyn <serge.hallyn@canonical.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org, keescook@chromium.org
Subject: Re: /proc/pid/fd/ shows strange mode when executed via sudo.
Date: Thu, 3 May 2012 10:42:22 -0500	[thread overview]
Message-ID: <20120503154222.GA8776@sergelap> (raw)
In-Reply-To: <201205022240.GBB13566.VOtHFOLFOMSJFQ@I-love.SAKURA.ne.jp>

Quoting Tetsuo Handa (penguin-kernel@I-love.SAKURA.ne.jp):
> I noticed a strange difference in /proc/pid/fd/ directory
> when a command is executed via /usr/bin/sudo.
> 
> Say, there are three files in some directory.
> (In my environment, /tmp/ is a plain ext4 partition.)
> 
> # touch /tmp/1
> # touch /tmp/2
> # touch /tmp/3
> # ls -l /tmp/?
> -rw-r--r-- 1 root root 0 May  2 21:48 /tmp/1
> -rw-r--r-- 1 root root 0 May  2 21:48 /tmp/2
> -rw-r--r-- 1 root root 0 May  2 21:48 /tmp/3
> 
> Try to read one of them using "tail -f" from one terminal.
> 
> # tail -f /tmp/1
> 
> Show /proc/pid/fd/ from another terminal.
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:54 0 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:54 1 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:54 2 -> /dev/pts/0
> lr-x------ 1 root root 64 May  2 21:54 3 -> /tmp/1
> lr-x------ 1 root root 64 May  2 21:54 4 -> anon_inode:inotify
> 
> Quit the "tail -f". Try to read two of them using "tail -f".
> 
> # tail -f /tmp/1 /tmp/2
> 
> Show /proc/pid/fd/ from another terminal.
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:54 0 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:54 1 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:54 2 -> /dev/pts/0
> lr-x------ 1 root root 64 May  2 21:54 3 -> /tmp/1
> lr-x------ 1 root root 64 May  2 21:54 4 -> /tmp/2
> lr-x------ 1 root root 64 May  2 21:54 5 -> anon_inode:inotify
> 
> Quit the "tail -f". Try to read three of them using "tail -f".
> 
> # tail -f /tmp/1 /tmp/2 /tmp/3
> 
> Show /proc/pid/fd/ from another terminal.
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:55 0 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:55 1 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:55 2 -> /dev/pts/0
> lr-x------ 1 root root 64 May  2 21:55 3 -> /tmp/1
> lr-x------ 1 root root 64 May  2 21:55 4 -> /tmp/2
> lr-x------ 1 root root 64 May  2 21:55 5 -> /tmp/3
> lr-x------ 1 root root 64 May  2 21:55 6 -> anon_inode:inotify
> 
> Quit the "tail -f". You see, they are all fine.
> 
> However, the output is different when executed via /usr/bin/sudo .
> 
> Try to read one of them using "sudo tail -f" from one terminal.
> 
> # sudo tail -f /tmp/1
> 
> Show /proc/pid/fd/ from another terminal.
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:55 0 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:55 1 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:55 2 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:55 3 -> /tmp/1
> lrwx------ 1 root root 64 May  2 21:55 4 -> anon_inode:inotify
> 
> Quit the "tail -f". Try to read two of them using "sudo tail -f".
> 
> # sudo tail -f /tmp/1 /tmp/2
> 
> Show /proc/pid/fd/ from another terminal.
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:56 0 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:56 1 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:56 2 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:56 3 -> /tmp/1
> lrwx------ 1 root root 64 May  2 21:56 4 -> /tmp/2
> lr-x------ 1 root root 64 May  2 21:56 5 -> anon_inode:inotify
> 
> Quit the "tail -f". Try to read three of them using "sudo tail -f".
> 
> # sudo tail -f /tmp/1 /tmp/2 /tmp/3
> 
> Show /proc/pid/fd/ from another terminal.
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:56 0 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:56 1 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:56 2 -> /dev/pts/0
> lrwx------ 1 root root 64 May  2 21:56 3 -> /tmp/1
> lrwx------ 1 root root 64 May  2 21:56 4 -> /tmp/2
> lr-x------ 1 root root 64 May  2 21:56 5 -> /tmp/3
> lr-x------ 1 root root 64 May  2 21:56 6 -> anon_inode:inotify
> 
> Quit the "tail -f".
> 
> You see, when executed via /usr/bin/sudo , fd == 3 and fd == 4 are reported as
> "lrwx------" whereas fd >= 5 are reported as "lr-x------".
> 
> # strace -f -e open sudo tail -f /tmp/1 /tmp/2 /tmp/3
> 
> shows that /usr/bin/tail is opening /tmp/1 /tmp/2 /tmp/3 as O_RDONLY.
> /usr/bin/sudo can't set w bit before /usr/bin/tail opens them with r bit.
> I wonder from where the w bit came...

Note that if you do

sudo strace -f -e open tail -f /tmp/{1,2,3,4}

then the fds are not opened with write perms.  But if you do as you did,

strace -f -e open sudo tail -f /tmp/1 /tmp/2 /tmp/3

they are.  Interesting.

The same thing also happens for me with tmpfs, and with a debian sid ec2
instance running 2.6.32-5-xen-amd64.

> Above result was obtained using kernel 3.2.0-24-generic-pae (3.2.0-24.37) on
> Ubuntu 12.04, but below result (similar but not identical) was obtained using
> vanilla 3.4-rc5 kernel on CentOS 6.2.
> 
> -- (normal case. normal result.)
> # tail -f /tmp/1 /tmp/2
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:04 0 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:04 1 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:04 2 -> /dev/pts/2
> lr-x------ 1 root root 64 May  2 21:04 3 -> /tmp/1
> lr-x------ 1 root root 64 May  2 21:04 4 -> /tmp/2
> lr-x------ 1 root root 64 May  2 21:04 5 -> anon_inode:inotify
> -- (sudo case. only fd == 3 got w bit.)
> # sudo tail -f /tmp/1 /tmp/2
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:05 0 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:05 1 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:05 2 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:05 3 -> /tmp/1
> lr-x------ 1 root root 64 May  2 21:05 4 -> /tmp/2
> lr-x------ 1 root root 64 May  2 21:05 5 -> anon_inode:inotify
> -- (normal case. normal result.)
> # tail -f /tmp/1 /tmp/2 /tmp/3
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:07 0 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:07 1 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:07 2 -> /dev/pts/2
> lr-x------ 1 root root 64 May  2 21:07 3 -> /tmp/1
> lr-x------ 1 root root 64 May  2 21:07 4 -> /tmp/2
> lr-x------ 1 root root 64 May  2 21:07 5 -> /tmp/3
> lr-x------ 1 root root 64 May  2 21:07 6 -> anon_inode:inotify
> -- (sudo case. fd == 3 and fd == 6 got w bit.)
> # sudo tail -f /tmp/1 /tmp/2 /tmp/3
> 
> # ls -l /proc/`pidof tail`/fd/
> total 0
> lrwx------ 1 root root 64 May  2 21:07 0 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:07 1 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:07 2 -> /dev/pts/2
> lrwx------ 1 root root 64 May  2 21:07 3 -> /tmp/1
> lr-x------ 1 root root 64 May  2 21:07 4 -> /tmp/2
> lr-x------ 1 root root 64 May  2 21:07 5 -> /tmp/3
> lrwx------ 1 root root 64 May  2 21:07 6 -> anon_inode:inotify
> 
> I guess something is wrong.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

next prev parent reply	other threads:[~2012-05-03 15:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-02 13:40 /proc/pid/fd/ shows strange mode when executed via sudo Tetsuo Handa
2012-05-03 15:42 ` Serge Hallyn [this message]
2012-05-03 16:25   ` Tetsuo Handa
2012-05-18  2:39     ` Tetsuo Handa
2012-05-18  9:27       ` Tetsuo Handa
2012-05-18 16:08         ` Linus Torvalds
2012-05-18 16:25           ` Linus Torvalds
2012-05-18 19:55             ` Eric W. Biederman
2012-05-18 18:08           ` Al Viro
2012-05-18 18:18             ` Linus Torvalds
2012-05-18 18:23               ` Linus Torvalds
2012-05-18 18:45                 ` Al Viro
2012-05-18 18:55                   ` Linus Torvalds
2012-05-18 19:10                     ` Al Viro
2012-05-18 20:49                       ` Linus Torvalds
2012-05-18 21:23                         ` Al Viro
2012-05-18 21:26                           ` Linus Torvalds
2012-05-18 21:32                             ` Linus Torvalds
2012-05-18 22:29                               ` Al Viro
2012-05-19  7:08                                 ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120503154222.GA8776@sergelap \
    --to=serge.hallyn@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Be sure your reply has a Subject: header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).