0 lrwx------ 1 foo group1 64 Feb 14 23:15 0 -> /dev/pts/3
Can I somehow change the permissions somehow so the other process can write to it?
Yes, but writing will probably not do what you want.
/dev/pts/3 is a pseudo-terminal slave device. The process you're after takes its input from a pseudo-terminal. You can change the permissions of such device with
chmod. The node named
0 will not reflect the change but
/dev/pts/3 will. To use the changed permissions you need to write to
/dev/pts/3, not to
The result will most likely not meet your expectations though. To explain it run a shell in a terminal emulator (
xterm) or in a terminal multiplexer (
screen) and invoke
ls -l /proc/$$/fd/. You will find the shell reads and writes to the same
pts. When it reads, it reads what you type. When it writes, it makes characters appear in the terminal.
The same will happen if you write to
/dev/pts/3: characters will appear in the terminal which provides input for the process in question. Your action will not inject input as if you typed in the terminal, i.e. it will not provide input for the process.
To inject input as if you typed, you would need to write to the corresponding master device. This is not trivial. In short:
On Linux, using
devpts, there is no master device file. The process on the master end uses a file descriptor, which it gets by opening
ptmx, but there’s no corresponding device node.
"The process on the master end" is the terminal emulator, terminal multiplexer,
sshd (if the client requested a pseudo-terminal),
However this other answer states:
There's a special ioctl (
TIOCSTI) which allows you to insert a byte into the input queue of a tty, as if it were received from the other end.
TIOCSTI will only work as root when not used on the controlling tty of the process calling it.
See the whole answer for details. I guess it may not be very useful for you because of the root access requirement.
The simplest way to (unidirectionally) connect two processes is to connect them with a pipe:
foo | bar
In case of processes that are about to be started by two different users, use a named pipe instead of unnamed pipe:
# any user
chmod … # allow access for the other user
Named pipes behave like you expected while pseudo-terminal slave devices don't.
bar are started with respective stdout and stdin already redirected. A running process can redirect its own stdin (e.g. shells can on demand) but there is no easy/elegant way to force it to.
E.g. if the process in question was an interactive
bash, you could make it redirect its stdin from
pipeA by invoking
exec 0<pipeA. Then from another console you could do like
echo date >pipeA and the shell would execute
date as if you typed it (and it would probably exit because all descriptors writing to the pipe are now closed; to avoid this open the named pipe in the shell also for writing in the first place: