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 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 ghostghost : users root tty wheelSeems 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