1

What I am trying to do:

I have a machine that is treated as an appliance, it has multiple graphical applications open, and these must not be closed at any time.

HumanA might turn on the system, launch the applications, then lock the screen.

There is a shift change, and HumanB now takes the responsibility of the machine.

HumanB now needs to log into the system, and see the same graphical applications that HumanA launched.

How I do it today

Today we achieve this by having one user account (UserX) and both HumanA and HumanB know the password to UserX.

The problem is with the auditing of this system. If we determine something very bad happened over the weekend, the log file would only tell us that UserX logged in. This fails to meet our regulations.

What I need it to do

I need HumanA and HumanB to not know each others password or a shared password.

I need HumanA and HumanB to he able to log in and see the same graphical user environment.

I need to be able to determine which Human logged in at what time, from an audit point of view.

** Clarifications **

This is a computer/monitor/keyboard setup, no remote or ssh sessions to worry about.

The humans don't use the system at the same time.

Any trick that involves "moving" the application can't cause any interruption in high performance computing tasks, even a 1 millisecond interruption is not acceptable.

We currently use yocto and XFCE.

The application can not be re-written or redesigned, it must remain graphical.

Improve this question
3
  • What stops you from running the application on one machine, then use different VNC over SSH accounts to access it - the SSH logs would show, who was logged in (via VNC) at the time something happened.
    – Eugen Rieck
    Commented Dec 4, 2020 at 21:42
  • If VNC could be used in a way that make it look and feel like you are just sitting down and logging into computer, like a normal desktop monitor setup. But if at any point the user has to use a different computer, or a key combination to switch screens/terminals, it sort of ruins the whole thing. We also need to think about things like rebooting the machine if necessary, how does that work? Who sets up the initial UserX application?
    – Miebster
    Commented Dec 4, 2020 at 21:51
  • The first thing should be doable via VNC, this is how a thin client works. On reboot you could have the "server" just auto-logon to Uxer X
    – Eugen Rieck
    Commented Dec 4, 2020 at 22:03

2 Answers 2

Reset to default
0

You could continue to have UserX open the graphical session, but add another application that does a screengrab over the graphical applications. HumanA can "log in" through that screengrab application. The application would record that HumanA is now operating the system.

At the end of a shift, HumanA "logs out" by restarting the screengrab application (over the long-running graphical applications), so when HumanB arrives, she must "log in" through the screengrab, and the user change can be recorded.

Improve this answer
0

It's a bit hackish, but I think you could manage it by using multiple users with the same uid. You could would have on /etc/passwd:

Appliance:x:1000:1000::/home/machine:/bin/bash
HumanA:x:1000:1000::/home/machine:/bin/bash
HumanB:x:1000:1000::/home/machine:/bin/bash

(plus corresponding entries on /etc/shadow, you may passwd HumanA)

The system actually identifies the users by their uid. So, with a setup like this, you can enter both HumanA (with HumanA's password) or HumanN (with HumanB's password), and you will end up at the same session. It will however log the user provided for login.

When the system wants to resolve uid 1000 to a name, it will find the first resullt and just return "Appliance".

The same trick could be performed with other nss providers, of course.

Improve this answer
1
  • This is clever, and I like it. My concern with this answer (and largely with the entire problem) is that whoever is logged in is able to take actions as the same user, so if they (for example) ran a program that delayed say 1 shift, and then took a malicious action, there is no auditing to show that it wasn't someone else delaying 2 shifts, or 3 shifts, etc. Maybe if the requester added keylogging or specified kernel level auditing of process creation, etc., you could tend to mitigate this risk.
    – Slartibartfast
    Commented Dec 5, 2020 at 17:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .