[9fans] on cp /fd/1 /fd/0

[9fans] on cp /fd/1 /fd/0

[Daniel Bastos]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

Good morning.

% cp /fd/1 /fd/0
cp: can't open /fd/1: '/fd/1' inappropriate use of fd

I can't open it for reading, but I could open it for writing. Why can't I
open it for reading?

[-- Attachment #2: Type: text/html, Size: 809 bytes --]

Re: [9fans] on cp /fd/1 /fd/0

[Iruatã Souza]

--r-------- d 0 glenda glenda 0 May 10 18:57 0
--rw------- d 0 glenda glenda 0 May 10 18:57 1
---w------- d 0 glenda glenda 0 May 10 18:57 2

is that what you want to know? or the reasons why the permissions are like that?

On Tue, May 12, 2015 at 8:56 AM, Daniel Bastos <dbastos@toledo.com> wrote:
> Good morning.
>
> % cp /fd/1 /fd/0
> cp: can't open /fd/1: '/fd/1' inappropriate use of fd
>
> I can't open it for reading, but I could open it for writing. Why can't I
> open it for reading?

Re: [9fans] on cp /fd/1 /fd/0

[lucio]

> --r-------- d 0 glenda glenda 0 May 10 18:57 0
> --rw------- d 0 glenda glenda 0 May 10 18:57 1
> ---w------- d 0 glenda glenda 0 May 10 18:57 2
>
> is that what you want to know? or the reasons why the permissions are like that?

Except that OP wants to know why reading /fd/1 isn't allowed when the
permissions allow it.  I suspect something is a bit obscure, like the
implementation being different from the stated permissions.

Lucio.

Re: [9fans] on cp /fd/1 /fd/0

[erik quanstrom]

> Except that OP wants to know why reading /fd/1 isn't allowed when the
> permissions allow it.  I suspect something is a bit obscure, like the
> implementation being different from the stated permissions.

i imagine that the permissions on the underlying device are wrong.
"cons" is 600 in rio, and i suspect that's it.  'd' is the dup driver.

- erik

Re: [9fans] on cp /fd/1 /fd/0

[Daniel Bastos]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Tue, May 12, 2015 at 9:24 AM, Iruatã Souza <iru.muzgo@gmail.com> wrote:

> --r-------- d 0 glenda glenda 0 May 10 18:57 0
> --rw------- d 0 glenda glenda 0 May 10 18:57 1
> ---w------- d 0 glenda glenda 0 May 10 18:57 2
>
> is that what you want to know? or the reasons why the permissions are like
> that?
>

I want to understand the system. (It makes sense to me that the permissions
are like that.)

What is the relationship between file descriptor 1 and /fd/1? When a
program runs, 1 is already open for writing. But apparently it's open only
for writing. A read on it yields inappropriate use of fd. The same seems to
happen /fd/1. Can I say they'll both always present the same behavior?

I'm not able to change permissions on /fd/1. Why not?

% ls -l /fd/1
---w------- d 0 dbastos dbastos 0 May 19  2014 /fd/1

% chmod u+r /fd/1
chmod: can't wstat /fd/1: permission denied

I'm studying. One thing I imagined was to write to standard output and be
able to read what I wrote.

[-- Attachment #2: Type: text/html, Size: 2330 bytes --]

Re: [9fans] on cp /fd/1 /fd/0

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On 12 May 2015 at 12:56, Daniel Bastos <dbastos@toledo.com> wrote:

> % cp /fd/1 /fd/0
> cp: can't open /fd/1: '/fd/1' inappropriate use of fd
>
> I can't open it for reading, but I could open it for writing. Why can't I
> open it for reading?
>

The file open on file descriptor 1 wasn't itself opened for reading, only
writing. Check with ls -l /fd/1:

h% ls -l /fd/0 /fd/1
--r-------- d 0 bootes bootes 0 Jul  2  2014 /fd/0
---w------- d 0 bootes bootes 0 Jul  2  2014 /fd/1

The "bootes" is wrong, though: the driver should use up->user (not
hostowner, or even the owner of the underlying file).
You'll notice that someone else had /fd/1 with both r and w, in which case
cp /fd/1 /fd/0 would instead have complained about /fd/0
since /fd/1 could be opened, but /fd/0 can't be written.

[-- Attachment #2: Type: text/html, Size: 1723 bytes --]

Re: [9fans] on cp /fd/1 /fd/0

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

On 12 May 2015 at 15:17, Daniel Bastos <dbastos@toledo.com> wrote:

> What is the relationship between file descriptor 1 and /fd/1? When a
> program runs, 1 is already open for writing. But apparently it's open only
> for writing. A read on it yields inappropriate use of fd. The same seems to
> happen /fd/1. Can I say they'll both always present the same behavior?
>

open /fd/1 and you get a new file descriptor number that refers to the same
open file as file descriptor 1, and with the same open mode
(the new open can add OCEXEC, which will apply to both). /fd/1ctl  shows
what you get.

I'm not able to change permissions on /fd/1. Why not?
>

Because if those changed permissions worked, that would in principle allow
you to force write access to  a file you'd opened with read.

The "inappropriate use" message is possibly a bad choice. It's normally
returned for attempting to write
to a file descriptor open for read (or conversely). The usual "permission
denied" message would be better for open.

[-- Attachment #2: Type: text/html, Size: 1726 bytes --]

Re: [9fans] on cp /fd/1 /fd/0

[Daniel Bastos]

On Tue, May 12, 2015 at 1:15 PM, Charles Forsyth
<charles.forsyth@gmail.com> wrote:
> On 12 May 2015 at 15:17, Daniel Bastos <dbastos@toledo.com> wrote:
>>
>> What is the relationship between file descriptor 1 and /fd/1? When a
>> program runs, 1 is already open for writing. But apparently it's open only
>> for writing. A read on it yields inappropriate use of fd. The same seems to
>> happen /fd/1. Can I say they'll both always present the same behavior?
>
> open /fd/1 and you get a new file descriptor number that refers to the same
> open file as file descriptor 1, and with the same open mode
> (the new open can add OCEXEC, which will apply to both). /fd/1ctl  shows
> what you get.

I don't follow you. The only way I could open successfully was to
specify OWRITE (with or without OCEXEC). The results were expected:
with OCEXEC, the fd was closed after an exec, without it it was kept
open. I don't know what you wanted to show me.

My conclusion is that

  cp /fd/1 anything

could never work because it requires opening /fd/1 for reading, which
is not possible. Is this conclusion incorrect?

Re: [9fans] on cp /fd/1 /fd/0

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On 12 May 2015 at 18:10, Daniel Bastos <dbastos@toledo.com> wrote:

> could never work because it requires opening /fd/1 for reading, which
> is not possible. Is this conclusion incorrect?
>

It's not right. I'll try again.

/fd/1 gives a name to file descriptor 1.
When opened, you get a new file descriptor (not 1) that refers to the same
open file instance as file descriptor 1.
If file descriptor 1 was opened with a given mode (M, say), then /fd/1 can
only
be opened with a mode compatible with mode M.
Opening for read (OREAD) works with existing mode M being OREAD or ORDWR;
opening for write (OWRITE) works with existing mode being OWRITE or ORDWR;
opening for read-write ( ORDWR) is compatible only with ORDWR.

If opening with /fd/1 returns a permission error (inappropriate use),
that's because
the mode used to open it wasn't compatible with the mode of the open or
create
that put an open file in file descriptor slot 1.

The file permission shown for /fd/N tells you the open mode of the
underlying file descriptor:
if only w, then only OWRITE, if only r, then OREAD, if rw, then ORDWR.

Finally, you can indeed open /fd/1 for reading if file descriptor 1 was
itself opened for read:

      h% rc <>[1]/dev/cons    # open /dev/cons read-write as file
descriptor 1
      h% ls -l /fd/1
--rw------- d 0 bootes bootes 0 Jul  2  2014 /fd/1   # it says it's
read-write
      h% echo hi >/fd/1    # i can write
hi
      h% read -n 1 /fd/1    # i can read
      hi yourself
hi yourself


Something I wrote earlier came out as the opposite of what I'd intended:

> (the new open can add OCEXEC, which will apply to both)

I don't know why I said that. I meant to write that it will "apply only to
the newly opened file".

[-- Attachment #2: Type: text/html, Size: 3559 bytes --]