Consider the following (C) code:

char c = 'A';
if (ioctl(0,TIOCSTI,&c)) perror("ioctl");

This works fine if the tty open on fd 0 is the current tty or if the
effective uid is 0.

However, if euid != 0 and I do something like:

$ ./program < /dev/pts/N

where N is not my current tty, then I get "Operation not permitted".

And (and this it the important part):
Even if I own /dev/pts/N and my processes are running on it.

I'm guessing this has something to do with process groups and not letting
you write into the other TTY (even if by the usual file security model, it
should be OK).

Is there any workaround (other than running as root, which isn't an option
on the actual system where I need to do this) ?

--
I shot a man on Fifth Aveneue, just to see him die.

gazelle@shell.xmission.com (Kenny McCormack) writes:
>Consider the following (C) code:
>
> char c = 'A';
> if (ioctl(0,TIOCSTI,&c)) perror("ioctl");
>
>This works fine if the tty open on fd 0 is the current tty or if the
>effective uid is 0.
>
>However, if euid != 0 and I do something like:
>
>$ ./program < /dev/pts/N
>
>where N is not my current tty, then I get "Operation not permitted".

That's a good thing.

It would be a crazy huge security hole to allow arbitrary character
injection into other terminals.

>
>And (and this it the important part):
> Even if I own /dev/pts/N and my processes are running on it.

Even then. Just because they have the same UID, doesn't mean
they are the same user (e.g. guest).

On 11/1/23 10:58, Kenny McCormack wrote:
> Consider the following (C) code:
>
> char c = 'A';
> if (ioctl(0,TIOCSTI,&c)) perror("ioctl");
>
> This works fine if the tty open on fd 0 is the current tty or if the
> effective uid is 0.
>
> However, if euid != 0 and I do something like:
>
> $ ./program < /dev/pts/N
>
> where N is not my current tty, then I get "Operation not permitted".
>
> And (and this it the important part):
> Even if I own /dev/pts/N and my processes are running on it.
>
> I'm guessing this has something to do with process groups and not letting
> you write into the other TTY (even if by the usual file security model, it
> should be OK).
>
> Is there any workaround (other than running as root, which isn't an option
> on the actual system where I need to do this) ?
>

Maybe you could create a named pipe? (mkfifo)
But, what are you trying to do here?
--
user <candycane> is generated from /dev/urandom

On 2023-11-01, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> Consider the following (C) code:
>
> char c = 'A';
> if (ioctl(0,TIOCSTI,&c)) perror("ioctl");
>
> This works fine if the tty open on fd 0 is the current tty or if the
> effective uid is 0.

Even under those conditions, it is a security hole.

Programs from different security domains share the same terminal.

For instance superuser can "su" to Mallory's account and run some
program as that user, then exit. What if that program pushes the
characters "rm -rf /bin\n" into the TTY.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.