A requirement for the current user to own ttys

[Konstantin I.]

Hi,

> Nope. Via "sudo", the first user is allowed to execute certain commands on 
> behalf of the second, not the other way around.

I didn't say "via sudo"

I said: the second user (`ghost` in this example) is authorised to act on 
behalf of `echo`.

How it's done is irrelevant. You mentioned PAM. Ok. Let it be PAM. Not sure 
how to set it up, but that's not important. sudo here is just used to 
switch from echo to ghost. How ghost then gains the access to echo's 
resources is a different question.

> Seems your 'ghost' is a pretty power user.

That doesn't matter. That could've been root. root is rejected to see the 
background as well. It doesn't sound sane to me.

>He has no direct access to the vcsa3 device

Or she, but anyway they have indirect access via the sticky bit. So it 
shouldn't be a problem.

> and the corresponding tty3 is owned by 'echo'. How do you think mc's 
> cons.saver should figure out that it's safe to grant access?

Please take a look at my ls -la outputs. Not only is tty3 owened by echo 
but it's owned also by the tty group. And as you saw ghost is a pretty 
powerful user. The user is a part of the tty group as well. But mc doesn't 
care. It also doesn't care whether this is root or not.

> implementing alternate screen support in the Linux tty driver, or using a 
>graphical emulator. I can't see how mc could solve this issue.

That would be overkilling. Why not just to follow standard *nix 
conventions? To respect root privileges at least. May I dare to ask to 
respect group permissions as well ;-)

--
With all my respect,
Konstantín





Sent with AquaMail for Android
http://www.aqua-mail.com


On 11 March 2017 12:41:00 pm Egmont Koblinger <egmont at gmail.com> wrote:

> Hi,
>
> The requirement here is that the second user (`ghost` in this example) is
>> authorised to act on behalf of `echo`.
>>
>
> Nope. Via "sudo", the first user is allowed to execute certain commands on
> behalf of the second, not the other way around. During this, the second
> user doesn't have any access to the first user's resources (e.g. files
> under its home). As such, it's utterly irrelevant whether tty3 is owned by
> 'echo' (the first user) or not. It's not owned by 'ghost' (the second
> user), so no access.
>
> If you wish to grant access to tty3 for 'ghost', this should be done by
> sudo or the pam framework or whatever, definitely not mc.
>
>
>> echo:/etc/init.d$ groups ghost
>> ghost : users root tty wheel
>>
>
> Seems your 'ghost' is a pretty power user. E.g. he can write to the tty
> devices, or even hijack the data that's being typed there. Definitely not
> something a regular user should have. Plus the root and wheel groups. As
> such, you might just as well put the vcsa devices in a group and chmod 660
> and hence allow the ghost user to directly access them.
>
>
>> Question: does mc work in this case as it was designed?
>>
>
> It's a compromise due to the lack of alternate screen support. I'd say mc
> was designed to paint on the alternate screen, but due to lack thereof it
> needed to find a workaround.
>
> behaviour I would expect: in the example above mc shouldn't stop after
>> executing commands and should show previous command output.
>>
>
> mc is being executed as user 'ghost'. He has no direct access to the vcsa3
> device, and the corresponding tty3 is owned by 'echo'. How do you think
> mc's cons.saver should figure out that it's safe to grant access?
>
>
>> 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?
>>
>
> Yup, like implementing alternate screen support in the Linux tty driver, or
> using a graphical emulator. I can't see how mc could solve this issue. If
> you can, let us know.
>
>
> cheers,
> egmont
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20170311/7b1e1b43/attachment.html>