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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.