Discussion:
Response to my recent thread about TIOCSTI
(too old to reply)
Kenny McCormack
2023-11-02 00:56:10 UTC
Permalink
Just to keep us all up to date, none of the responses (*) so far have been
either useful or on-topic. This is not to disparage the writers of those
responses, but rather to advise other possible responders that the status
of the question is still: Open. And that any useful and topical response
from them would still be welcome and greatly appreciated.

Note that I have no interest in debating any of the topics raised by those
responders, but those posters should feel free to start threads of their
own in which these topics can be discussed, if they are so inclined.

(*) On the TIOCSTI thread.
--
Note that Oprah actually is all the things that The Donald only wishes he were.
For one thing, she actually *is* a billionaire. She's also actually self-made,
came from nothing, knows how to run businesses, never went bankrupt, is smart
and is mentally stable.
Kaz Kylheku
2023-11-02 01:10:51 UTC
Permalink
Post by Kenny McCormack
(*) On the TIOCSTI thread.
TIOCSTI is a gaping, ancient security hole.

OpenBSD has removed it.

Linux merged a commit which allows TIOCSTI to be disabled.
This has discussion in the commit message.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.6&id=83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d

I can easily see the default changing to disabled by default in the
future, and the thing completely disappearing.

That's all there is to it.

Don't write new code which uses this; it's not guaranteed to be there.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Kenny McCormack
2023-11-02 01:34:45 UTC
Permalink
Post by Kaz Kylheku
Post by Kenny McCormack
(*) On the TIOCSTI thread.
TIOCSTI is a gaping, ancient security hole.
More off-topic text. But, as noted, feel free to start a new thread to
talk all you want about it. Or anything else that happens to be on your
mind.
--
What are your thoughts on Alabama politicians declaring Donald Trump one
of the greatest presidents ever?

Alabama is ranked #47 in education out of 50 states. Now we know why.
Kaz Kylheku
2023-11-02 02:24:04 UTC
Permalink
Post by Kenny McCormack
Post by Kaz Kylheku
Post by Kenny McCormack
(*) On the TIOCSTI thread.
TIOCSTI is a gaping, ancient security hole.
More off-topic text. But, as noted, feel free to start a new thread to
talk all you want about it. Or anything else that happens to be on your
mind.
The issue is that who owns /dev/pts/N (as in the ownership and
permissions you see if you run "ls -l /dev/pts/N" don't determine
every aspect of what you can do with the TTY device.

Once open, TTY descriptor can be shared by multiple processes
which run in different security domains; it would be a bad idea
to be able to stuff input into them.

(There are other ways to stuff input, via external loopback.
That's what security holes in terminal emulators are about:
situations whereby a terminal will echo back a string sent to it.)

One kernel version (that I happen to work with) routes that ioctl
to this function:

static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;

if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
return -EFAULT;
tty_audit_tiocsti(tty, ch);
ld = tty_ldisc_ref_wait(tty);
if (!ld)
return -EIO;
if (ld->ops->receive_buf)
ld->ops->receive_buf(tty, &ch, &mbz, 1);
tty_ldisc_deref(ld);
return 0;
}

So the check you have discovered is done upfront before anything. If this is
not your controlling tty, and you don't have admin caps, then EPERM.

The code is the code; the reason you see the behavior is that the code is what
it is, and that is the way it is due to the security aspect of TIOCSTI.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
candycanearter07
2023-11-02 06:26:17 UTC
Permalink
Post by Kaz Kylheku
Post by Kenny McCormack
Post by Kaz Kylheku
Post by Kenny McCormack
(*) On the TIOCSTI thread.
TIOCSTI is a gaping, ancient security hole.
More off-topic text. But, as noted, feel free to start a new thread to
talk all you want about it. Or anything else that happens to be on your
mind.
The issue is that who owns /dev/pts/N (as in the ownership and
permissions you see if you run "ls -l /dev/pts/N" don't determine
every aspect of what you can do with the TTY device.
Once open, TTY descriptor can be shared by multiple processes
which run in different security domains; it would be a bad idea
to be able to stuff input into them.
(There are other ways to stuff input, via external loopback.
situations whereby a terminal will echo back a string sent to it.)
One kernel version (that I happen to work with) routes that ioctl
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
return -EFAULT;
tty_audit_tiocsti(tty, ch);
ld = tty_ldisc_ref_wait(tty);
if (!ld)
return -EIO;
if (ld->ops->receive_buf)
ld->ops->receive_buf(tty, &ch, &mbz, 1);
tty_ldisc_deref(ld);
return 0;
}
So the check you have discovered is done upfront before anything. If this is
not your controlling tty, and you don't have admin caps, then EPERM.
The code is the code; the reason you see the behavior is that the code is what
it is, and that is the way it is due to the security aspect of TIOCSTI.
Why does it return negative error codes?
--
user <candycane> is generated from /dev/urandom
Kenny McCormack
2023-11-02 06:35:58 UTC
Permalink
In article <uhvfe9$1pbr3$***@dont-email.me>,
candycanearter07 <***@thanks.net> wrote:
...
Post by candycanearter07
Why does it return negative error codes?
I don't know. Why don't you start a new thread where you and he can
discuss this to your mutual heart's content?
--
If your answer to the question below is any number other than 1, then you're an atheist.

Q: How many religions are worthy of respect? (i.e., how many religions are valid?)
Kaz Kylheku
2023-11-02 15:50:21 UTC
Permalink
Post by Kenny McCormack
...
Post by candycanearter07
Why does it return negative error codes?
I don't know. Why don't you start a new thread where you and he can
discuss this to your mutual heart's content?
The most probable answer to that that candycanearter07 already started a
subthread for that purpose, as is the long-standing prevalent practice.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
candycanearter07
2023-11-02 18:44:56 UTC
Permalink
Post by Kaz Kylheku
Post by Kenny McCormack
...
Post by candycanearter07
Why does it return negative error codes?
I don't know. Why don't you start a new thread where you and he can
discuss this to your mutual heart's content?
The most probable answer to that that candycanearter07 already started a
subthread for that purpose, as is the long-standing prevalent practice.
Wait, are you supposed to create a new thread or a sub thread? How do
you create a new thread replying to a message?
--
user <candycane> is generated from /dev/urandom
Nicolas George
2023-11-02 20:26:02 UTC
Permalink
Post by candycanearter07
Wait, are you supposed to create a new thread or a sub thread? How do
you create a new thread replying to a message?
You reply, and the reply itself is a one-message sub-thread. Then if people
reply to the reply, it becomes the start of a non-trivial sub-thread.
Kaz Kylheku
2023-11-02 15:43:19 UTC
Permalink
Post by candycanearter07
Post by Kaz Kylheku
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
Why does it return negative error codes?
That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.

The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
candycanearter07
2023-11-02 18:56:56 UTC
Permalink
Post by Kaz Kylheku
Post by candycanearter07
Post by Kaz Kylheku
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
Why does it return negative error codes?
That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.
The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).
Oh cool, is that why so many C calls return -1 on error? I always
wondered about that..
--
user <candycane> is generated from /dev/urandom
Scott Lurndal
2023-11-02 20:58:10 UTC
Permalink
Post by candycanearter07
Post by Kaz Kylheku
Post by candycanearter07
Post by Kaz Kylheku
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
Why does it return negative error codes?
That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.
The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).
Oh cool, is that why so many C calls return -1 on error? I always
wondered about that..
Returning -1 on system call failure dates back to the first
versions of Unix. It was standardized by SVID and ultimately
POSIX.
candycanearter07
2023-11-02 21:06:11 UTC
Permalink
Post by Scott Lurndal
Post by candycanearter07
Post by Kaz Kylheku
Post by candycanearter07
Post by Kaz Kylheku
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
Why does it return negative error codes?
That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.
The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).
Oh cool, is that why so many C calls return -1 on error? I always
wondered about that..
Returning -1 on system call failure dates back to the first
versions of Unix. It was standardized by SVID and ultimately
POSIX.
Cool to know!
--
user <candycane> is generated from /dev/urandom
M***@dastardlyhq.com
2023-11-03 16:23:16 UTC
Permalink
On Thu, 02 Nov 2023 20:58:10 GMT
Post by Scott Lurndal
Post by candycanearter07
Post by Kaz Kylheku
Post by candycanearter07
Post by Kaz Kylheku
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
Why does it return negative error codes?
That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.
The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).
Oh cool, is that why so many C calls return -1 on error? I always
wondered about that..
Returning -1 on system call failure dates back to the first
versions of Unix. It was standardized by SVID and ultimately
POSIX.
Though if they were going to return -1 as a fail then it would have made a lot
more sense to return the negative error and dispense with errno altogether
except where an integer error can't be returned.

And just to confuse matters, the pthreads library functions DO return the error
code but its a positive value.
Scott Lurndal
2023-11-03 16:37:16 UTC
Permalink
Post by M***@dastardlyhq.com
On Thu, 02 Nov 2023 20:58:10 GMT
Post by Scott Lurndal
Post by candycanearter07
Post by Kaz Kylheku
Post by candycanearter07
Post by Kaz Kylheku
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
Why does it return negative error codes?
That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.
The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).
Oh cool, is that why so many C calls return -1 on error? I always
wondered about that..
Returning -1 on system call failure dates back to the first
versions of Unix. It was standardized by SVID and ultimately
POSIX.
Though if they were going to return -1 as a fail then it would have made a lot
more sense to return the negative error and dispense with errno altogether
except where an integer error can't be returned.
And just to confuse matters, the pthreads library functions DO return the error
code but its a positive value.
The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).
M***@dastardlyhq.com
2023-11-03 16:49:35 UTC
Permalink
On Fri, 03 Nov 2023 16:37:16 GMT
Post by Scott Lurndal
Post by M***@dastardlyhq.com
On Thu, 02 Nov 2023 20:58:10 GMT
Post by Scott Lurndal
Post by candycanearter07
Post by Kaz Kylheku
Post by candycanearter07
Post by Kaz Kylheku
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
Why does it return negative error codes?
That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.
The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).
Oh cool, is that why so many C calls return -1 on error? I always
wondered about that..
Returning -1 on system call failure dates back to the first
versions of Unix. It was standardized by SVID and ultimately
POSIX.
Though if they were going to return -1 as a fail then it would have made a lot
more sense to return the negative error and dispense with errno altogether
except where an integer error can't be returned.
And just to confuse matters, the pthreads library functions DO return the
error
Post by M***@dastardlyhq.com
code but its a positive value.
The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).
Makes sense. Though I'd be interested in knowing what the original logic was
in returning -1 and setting a seperate error variable instead of just returning
the error directly.
Scott Lurndal
2023-11-03 17:04:48 UTC
Permalink
Post by M***@dastardlyhq.com
On Fri, 03 Nov 2023 16:37:16 GMT
Post by Scott Lurndal
Post by M***@dastardlyhq.com
On Thu, 02 Nov 2023 20:58:10 GMT
Post by Scott Lurndal
Post by candycanearter07
Post by Kaz Kylheku
Post by candycanearter07
Post by Kaz Kylheku
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
Why does it return negative error codes?
That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.
The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).
Oh cool, is that why so many C calls return -1 on error? I always
wondered about that..
Returning -1 on system call failure dates back to the first
versions of Unix. It was standardized by SVID and ultimately
POSIX.
Though if they were going to return -1 as a fail then it would have made a lot
more sense to return the negative error and dispense with errno altogether
except where an integer error can't be returned.
And just to confuse matters, the pthreads library functions DO return the
error
Post by M***@dastardlyhq.com
code but its a positive value.
The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).
Makes sense. Though I'd be interested in knowing what the original logic was
in returning -1 and setting a seperate error variable instead of just returning
the error directly.
It's probably in the Lion's commentary somewhere.

https://en.wikipedia.org/wiki/A_Commentary_on_the_UNIX_Operating_System

My copy is in a box somewhere.
Rainer Weikusat
2023-11-03 17:23:47 UTC
Permalink
Post by M***@dastardlyhq.com
On Fri, 03 Nov 2023 16:37:16 GMT
[...]
Post by M***@dastardlyhq.com
Post by Scott Lurndal
Post by M***@dastardlyhq.com
Though if they were going to return -1 as a fail then it would have made a lot
more sense to return the negative error and dispense with errno altogether
except where an integer error can't be returned.
And just to confuse matters, the pthreads library functions DO return the
error
Post by M***@dastardlyhq.com
code but its a positive value.
The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).
Makes sense. Though I'd be interested in knowing what the original logic was
in returning -1 and setting a seperate error variable instead of just returning
the error directly.
At least up to 7th edition UNIX, system error codes didn't exist at
all. Functions returning integers would return -1 to indicate that an
error had occurred and the possible causes of such errors were listed in
the corresponding manual page.
Kaz Kylheku
2023-11-03 17:38:42 UTC
Permalink
Post by Scott Lurndal
The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).
Say, Scott, I wonder whether it's defined to do this:

{
int *errno_loc = &errno;

// then access *errno_loc multiple times in the scope
// with less overhead
}

E.g.:

*errno_loc = 0;
long val = strtol(..., ...);

if ((val == LONG_MAX || val == LONG_MIN) && *errno_loc != 0)
{
// out of range
}
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Scott Lurndal
2023-11-03 18:48:35 UTC
Permalink
Post by Kaz Kylheku
Post by Scott Lurndal
The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).
{
int *errno_loc = &errno;
// then access *errno_loc multiple times in the scope
// with less overhead
}
Close enough.

/* Function to get address of global `errno' variable. */
extern int *__errno_location (void) __THROW __attribute__ ((__const__));


# define errno (*__errno_location ())
Kenny McCormack
2023-11-03 20:23:46 UTC
Permalink
Post by Scott Lurndal
The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).
I hate having to killfile my own thread.
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Security
Philip Guenther
2023-11-05 04:24:11 UTC
Permalink
Post by Kenny McCormack
Post by Scott Lurndal
The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).
I hate having to killfile my own thread.
So you missed the post where Kaz suggested the process would need to make the target tty its controlling tty? That's unfortunate.

Philip Guenther
Kaz Kylheku
2023-11-03 17:36:04 UTC
Permalink
Post by M***@dastardlyhq.com
Though if they were going to return -1 as a fail then it would have made a lot
more sense to return the negative error and dispense with errno altogether
except where an integer error can't be returned.
errno is a complete stupidity, and some of the coding practices that you
have to use around it are even worse.

Like if you want to know whether a LONG_MAX or LONG_MIN return out of
strtol is a legitimate conversion or an error, you have to assign 0 to
errno first, and then check for a nonzero value if LONG_MAX or LONG_MIN
is returned.

(A co-op student could design a better API. Pointer to long where the
result is stored, and int return value.)

When a complex library function fails, which calls multiple system
calls, it's anyone's guess whether or how the value in errno pertains to
the failure cause.
Post by M***@dastardlyhq.com
And just to confuse matters, the pthreads library functions DO return the error
code but its a positive value.
Under threads, the errno expression expands to something like
(*__calculate_thread_specific_errno_location()) which is an expensive
function call.

Whoever designed the threads API would naturally have cringed at the
thought of the caller having to inspect errno after seeing a -1 value.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Rainer Weikusat
2023-11-03 16:56:49 UTC
Permalink
[...]
Post by candycanearter07
Post by Kaz Kylheku
One kernel version (that I happen to work with) routes that ioctl
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) &&
!capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
return -EFAULT;
tty_audit_tiocsti(tty, ch);
ld = tty_ldisc_ref_wait(tty);
if (!ld)
return -EIO;
if (ld->ops->receive_buf)
ld->ops->receive_buf(tty, &ch, &mbz, 1);
tty_ldisc_deref(ld);
return 0;
}
So the check you have discovered is done upfront before anything. If this is
not your controlling tty, and you don't have admin caps, then EPERM.
The code is the code; the reason you see the behavior is that the code is what
it is, and that is the way it is due to the security aspect of TIOCSTI.
Why does it return negative error codes?
That's the usual Linux (possibly also elsewhere) convention: Code which
doesn't really care about the specific error value can check if the
result of the function is negative. If so, an error occurred. It can
then do whatever error path processing is needed, eg, decrement
reference counts or free locks, and return the value as is to its
caller. In this way, it'll eventually be propagated to userspace.
vallor
2023-11-09 19:44:04 UTC
Permalink
On Thu, 2 Nov 2023 02:24:04 -0000 (UTC), Kaz Kylheku
Post by Kaz Kylheku
Post by Kenny McCormack
Post by Kaz Kylheku
Post by Kenny McCormack
(*) On the TIOCSTI thread.
TIOCSTI is a gaping, ancient security hole.
More off-topic text. But, as noted, feel free to start a new thread to
talk all you want about it. Or anything else that happens to be on
your mind.
The issue is that who owns /dev/pts/N (as in the ownership and
permissions you see if you run "ls -l /dev/pts/N" don't determine every
aspect of what you can do with the TTY device.
Once open, TTY descriptor can be shared by multiple processes which run
in different security domains; it would be a bad idea to be able to
stuff input into them.
(There are other ways to stuff input, via external loopback.
situations whereby a terminal will echo back a string sent to it.)
One kernel version (that I happen to work with) routes that ioctl to
static int tiocsti(struct tty_struct *tty, char __user *p)
{
char ch, mbz = 0;
struct tty_ldisc *ld;
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
return -EFAULT;
tty_audit_tiocsti(tty, ch);
ld = tty_ldisc_ref_wait(tty);
if (!ld)
return -EIO;
if (ld->ops->receive_buf)
ld->ops->receive_buf(tty, &ch, &mbz, 1);
tty_ldisc_deref(ld);
return 0;
}
So the check you have discovered is done upfront before anything. If
this is not your controlling tty, and you don't have admin caps, then
EPERM.
The code is the code; the reason you see the behavior is that the code
is what it is, and that is the way it is due to the security aspect of
TIOCSTI.
This is about as on-topic and useful as he could hope for, including
the code from the OS itself.

And I for one appreciated the time you took to post it. Thank you.
--
-v
Kenny McCormack
2023-11-10 04:16:26 UTC
Permalink
In article <uijcq4$2alo4$***@dont-email.me>, vallor <***@cultnix.org> wrote:
...
Post by vallor
This is about as on-topic and useful as he could hope for, including
the code from the OS itself.
Nope. Sorry.

It is as if I posted "I have a cold (or COVID)" and the response was a
detailed description of how viruses (*) exist and develop. Interesting
perhaps, but not at all helpful or on-topic.

(*) Viruses in the biological sense, not the computer sense.
--
Life's big questions are big in the sense that they are momentous. However, contrary to
appearances, they are not big in the sense of being unanswerable. It is only that the answers
are generally unpalatable. There is no great mystery, but there is plenty of horror.
(https://en.wikiquote.org/wiki/David_Benatar)
Kaz Kylheku
2023-11-10 04:24:12 UTC
Permalink
Post by Kenny McCormack
...
Post by vallor
This is about as on-topic and useful as he could hope for, including
the code from the OS itself.
Nope. Sorry.
It is as if I posted "I have a cold (or COVID)" and the response was a
detailed description of how viruses (*) exist and develop. Interesting
perhaps, but not at all helpful or on-topic.
It's all on-topic for the newsgroup. But of course you mean off-topic in
your bubble.

That's where it gets curious, because how can the the piece of code that
actually does the check that you were running into and asking about be
off topic?

"Not the whole answer" and "off topic" are different concepts.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Scott Lurndal
2023-11-10 14:55:26 UTC
Permalink
Post by Kaz Kylheku
Post by Kenny McCormack
...
Post by vallor
This is about as on-topic and useful as he could hope for, including
the code from the OS itself.
Nope. Sorry.
It is as if I posted "I have a cold (or COVID)" and the response was a
detailed description of how viruses (*) exist and develop. Interesting
perhaps, but not at all helpful or on-topic.
It's all on-topic for the newsgroup. But of course you mean off-topic in
your bubble.
That's where it gets curious, because how can the the piece of code that
actually does the check that you were running into and asking about be
off topic?
"Not the whole answer" and "off topic" are different concepts.
I've you been paying any attention at all for the last decade,
Kenny has never contributed anything useful other than insults.

Loading...