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


On 11 March 2017 at 04:37, Egmont Koblinger <egm...@gmail.com> wrote:

> Hi,
>
> > All you say about vcs* sounds reasonable, unfortunately according to the
> code, the tty owner is the problem.
>
> What do you mean the tty owner is the _problem_? What kind of problem?
>
> I believe it's not the _problem_, it's the piece of information we rely on
> to figure out if cons.saver is being run as a legitime user.
>
> > Disregarding of what was the intention,  disregarding of what you were
> trying to achieve and what security hole to close, do you think, that sort
> of comparison is valid here?
>
> I'm not aware of the details of the code and don't have time to dig into
> it, sorry.
>
> As far as I understand, your problem is: You expect that if the real user
> is root, cons.saver should dutifully perform its role rather than bail out
> due to some ownership mismatch. Am I right? If so, I believe it's a fair
> request, although possible security implications should be double checked.
> Could you please file a new bug for this?
>
> Thanks,
> egmont
>
>
_______________________________________________
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Reply via email to