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 <egm...@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
_______________________________________________
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
