1

From a discussion on useless use of cat.

I decided to see if It was possible to avoid some of the troubles by changing the owner of the pipe. So I did:

# cat | cat &
[1] 16500
# cd /proc/16500/fd
# ls -l
lr-x------ root root 0 -> pipe:[931613]
lrwx------ root root 1 -> /dev/tty1
lrwx------ root root 2 -> /dev/tty1
# chown --dereference daemon 0
# ls -l
lr-x------ root root 0 -> pipe:[931613]
lrwx------ root root 1 -> /dev/tty1
lrwx------ root root 2 -> /dev/tty1

I also tried chown and chown -L. No go. I'm convinced this is simply impossible, but why? They clearly have inodes. That 931613 is the inode number.

In the case I am actually interested in, the process on the right would be running at lower privileges and I'd kind of like it to own its own handles so that it can re-open them.

closed as off-topic by Stephen Harris, muru, roaima, Kusalananda Apr 13 at 7:04

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Harris, muru, roaima, Kusalananda
If this question can be reworded to fit the rules in the help center, please edit the question.

0

Turns out I goofed up my ls command.

# ls -lL
lr-x------ daemon root 0 -> pipe:[931613]
lrwx------ root   root 1 -> /dev/tty1
lrwx------ root   root 2 -> /dev/tty1

This was not a typo. This was an error in logic that happens to be fixed with one character. You see, I know these nodes aren't really symbolic links because opening them yields the correct file even if it was opened in a chroot jail, which yields an incorrect path in the ls -l output. Somehow I thought the kernel system call returned more attributes of the underlying inode than it actually does.

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