A requirement for the current user to own ttys
Key Offecka
key.offecka at gmail.com
Sat Mar 11 15:24:42 UTC 2017
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 <egmont at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20170311/95fdc357/attachment.html>
More information about the mc-devel
mailing list