(*) On the TIOCSTI thread.
On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
(*) On the TIOCSTI thread.
TIOCSTI is a gaping, ancient security hole.
In article <20231101180448.335@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
(*) 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.
On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
In article <20231101180448.335@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
(*) 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.
Why does it return negative error codes?
In article <uhvfe9$1pbr3$5@dont-email.me>,
candycanearter07 <no@thanks.net> wrote:
...
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?
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?
On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
In article <uhvfe9$1pbr3$5@dont-email.me>,
candycanearter07 <no@thanks.net> wrote:
...
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.
On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
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).
candycanearter07 <no@thanks.net> writes:
On 11/2/23 10:43, Kaz Kylheku wrote:
On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
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.
Wait, are you supposed to create a new thread or a sub thread? How do
you create a new thread replying to a message?
On 11/2/23 10:43, Kaz Kylheku wrote:
On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
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..
On Thu, 02 Nov 2023 20:58:10 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
candycanearter07 <no@thanks.net> writes:
On 11/2/23 10:43, Kaz Kylheku wrote:
On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
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.
candycanearter07 <no@thanks.net> writes:
On 11/2/23 10:43, Kaz Kylheku wrote:
On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
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.
Muttley@dastardlyhq.com writes:
On Thu, 02 Nov 2023 20:58:10 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
candycanearter07 <no@thanks.net> writes:
On 11/2/23 10:43, Kaz Kylheku wrote:
On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
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).
On 11/1/23 21:24, Kaz Kylheku wrote:
On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
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.
Why does it return negative error codes?
On Fri, 03 Nov 2023 16:37:16 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
On Thu, 02 Nov 2023 20:58:10 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
candycanearter07 <no@thanks.net> writes:
On 11/2/23 10:43, Kaz Kylheku wrote:
On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
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).
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.
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.
On Fri, 03 Nov 2023 16:37:16 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
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).
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.
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).
On 2023-11-03, Scott Lurndal <scott@slp53.sl.home> wrote:
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
}
On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
In article <20231101180448.335@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
(*) 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.
This is about as on-topic and useful as he could hope for, including
the code from the OS itself.
In article <uijcq4$2alo4$2@dont-email.me>, vallor <vallor@cultnix.org> wrote:
...
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.
On 2023-11-10, Kenny McCormack <gazelle@shell.xmission.com> wrote:
In article <uijcq4$2alo4$2@dont-email.me>, vallor <vallor@cultnix.org> wrote:
...
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 308 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 93:38:29 |
| Calls: | 6,923 |
| Calls today: | 1 |
| Files: | 12,383 |
| Messages: | 5,434,168 |