Re: A requirement for the current user to own ttys
- From: Key Offecka <key offecka gmail com>
- To: Egmont Koblinger <egmont gmail com>
- Cc: mc devel <mc-devel gnome org>
- Subject: Re: A requirement for the current user to own ttys
- Date: Sat, 11 Mar 2017 10:24:42 -0500
Hi Egmont,
> What do you mean the tty owner is the _problem_? What kind of problem?
Please excuse me, I wasn't quite correct there.
Let's forget about permissions and TTYs. Let's look at the issue from the user point of view. Please consider this case:
There is a user, say `echo` and there is another user, say `ghost`. It can also be `root` but that is not necessary. The requirement here is that the second user (`ghost` in this example) is authorised to act on behalf of `echo`. User `echo` logs on a tty, say tty3. In terms of permissions (OK, it's difficult to forget about them), ghost is a part of the tty group
echo:/etc/init.d$ ls -la /dev/tty3
crw-rw---- 1 echo tty 4, 3 mar 11 09:40 /dev/tty3
echo:/etc/init.d$ groups ghost
ghost : users root tty wheel
echo:/usr/lib/mc$ ls -la cons.saver
-rwsr-sr-x 1 vcsa root 10144 mar 11 09:49 cons.saver
echo:/usr/lib/mc$ ls -la /dev/vcs{,{,a}3}
crw------- 1 vcsa root 7, 0 mar 11 09:28 /dev/vcs
crw------- 1 vcsa root 7, 3 mar 11 09:28 /dev/vcs3
crw------- 1 vcsa root 7, 131 mar 11 09:28 /dev/vcsa3
The logged in user `echo` does sudo like so
sudo -u ghost mc
Now we execute a command in mc, mc runs it but before returning back it shows that ugly message about any key. If we press something, we return to the normal mc panels, but if we want to see the printed results of the previously executed command, we see the blank screen.
Question: does mc work in this case as it was designed?
The behaviour I would expect: in the example above mc shouldn't stop after executing commands and should show previous command output.
The same issue is valid for root, root is just more obvious example of the misbehaviour.
And the reason of the misbehaviour in my opinion is that there is a requirement for the tty to be owned by `ghost` in this example. And as I mentioned several times before, this comes from this sort of comparison
fstat (console_fd, &st) < 0 || st.st_uid != uid
That piece of information shouldn't be used like so. I think to achieve the goals you mentioned above (to not allow others to see what they shouldn't see) another solution should be found. Do you agree?
--
Konstantin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]