public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Andreas Schwab <schwab@suse.de>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: RFC: /dev/stdin, symlinks & permissions
Date: Tue, 18 Mar 2008 10:24:03 +0300	[thread overview]
Message-ID: <47DF6E13.5050709@msgid.tls.msk.ru> (raw)
In-Reply-To: <jeabkwaou7.fsf@sykes.suse.de>

Andreas Schwab wrote:
> Michael Tokarev <mjt@tls.msk.ru> writes:
> 
>>   # ls -l /dev/pts/0
>>   crw--w---- 1 root tty 136, 0 Mar 18 02:19 /dev/pts/0
>>
>> So far so good.  Now, I change uid to something else, --
>> doing su(8) to "mjt".  /proc/self changed obviously,
>> but stdin &Co is still here, and points to the same
>> /dev/pts/0.  But *its* permissions/ownership did not
>> change!  So now I can't, for example,
>>
>>  $ echo x > /dev/stdout
>>  bash: /dev/stdout: Permission denied
>>
>> which is quite unexpected - I for one expect /dev/stdout
>> to work the way very similar to /dev/tty, to mean "current
>> standard output regardless of any permissions etc".
> 
> This has nothing to do with /dev/stdout.  Your terminal simply does not
> allow access by anyone except user root or group tty.  You need to open
> it up first, or mount /dev/pts with broader permissions (which is a bad
> idea however).

No, you don't understand.  It has nothing to do with permissions
to the actual file /dev/stdin refers to, be it a tty or something
else.

In the exact same situation, I don't have to do anything with
/dev/tty (which refers to the same tty at the end) - it
Just Works (tm).  Ditto on Solaris for example, --
/dev/stdin etc Just Works too.  But not on Linux.

Without digging into implementation details (in this case it's
the fact that /dev/stdin in linux is implemented using a symlink
to - f.e. - /dev/tty/0 etc), I expect /dev/stdin to always work
as far as filedescriptor 0 is open, regardless of any permissions
on the actual tty (if it's a tty in the first place, which is
not necessary the case) -- exactly the same as /dev/tty works.

It's more:  I can redirect stdout of a process to some file,
and at that point /dev/stdout will return ENOENT on open.

The question is:

Are /dev/stdin &Co on linux are just convenience symlinks to
know where your std* files are (if so, why they're in /dev
and why they're so INconvenient - so many levels of symlinks), --
ie, the only thing I can do with them is ls/readlink them,
or are they supposed to actually WORK, ie, I'm able to open
them, as on other systems?

Thanks.

/mjt

  reply	other threads:[~2008-03-18  7:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-17 23:26 RFC: /dev/stdin, symlinks & permissions Michael Tokarev
2008-03-17 23:54 ` Andreas Schwab
2008-03-18  7:24   ` Michael Tokarev [this message]
2008-03-18 12:54     ` Theodore Tso
2008-03-18 14:32       ` Al Viro
2008-03-18 15:04         ` Theodore Tso
2008-03-23 16:50           ` H. Peter Anvin
2008-03-23  4:35         ` Denys Vlasenko

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=47DF6E13.5050709@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwab@suse.de \
    /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