Providing a way to pre-authorize applications to portals

[Conan-Kudo]

Some of the feedback I've been made aware of is that applications like Veyon don't have a path to Wayland right now, because they are exclusively deployed in mass-managed computing environments that are ultimately not designed for the user of the machine (children in classrooms) to have the capability to authorize portal access.

This is actually a problem for adoption of Linux in schools, because (at least in many states in the United States) schools are obligated to maintain and leverage computer monitoring in the name of maintaining the child's safety (particularly for early detection of thoughts of self-harm and such).

Can we come up with some kind of framework to allow systems administrators to pre-authorize applications in some fashion that can be deployed through custom packages or configuration management so that user prompts don't show up and the application is automatically granted the needed privileges when it requests it?

[idoric]

In France the NetSupport School software is very popular, and Veyon is the only open source alternative still maintained to this day, what's more, it is the only one capable of managing Linux clients. There is no requirement to install such software at the state level, but most local governments make it a necessary condition in public tenders. Last year I had the opportunity to deploy Linux on a room of old computers (instead of Windows 7). One of the necessary conditions set by the teachers was to have an equivalent of NetSupport School¹.

To get Veyon functional, I had to switch GNOME sessions back from Wayland to Xorg. At the time this solution was satisfactory, but when I see that Fedora 40 will only offer Plasma 6 in the Wayland version, I tell myself that the options for installing Veyon will slowly start to narrow down. And in the meantime, Wayland is increasingly the default option, which doesn't help with Veyon installation.

One point seems important to me, which is that in this use case many students can connect (via LDAP or Active Directory for example) to the same station over the course of weeks and months. Permanent authorization should therefore not be given at the user level, but at the machine level, regardless of who is connecting to it.

¹ Unlike what @Conan-Kudo mentions, in my case it's more for educational reasons: see at a glance the progress of all the students (thumbnail images of all screens simultaneously), locking of the screen and keyboard to capture the attention of students, taking control to help a student without having to go over their shoulders to access their keyboard and mouse, display the teacher's (or a student's) screen for all (other) students , launch an application on all workstations, etc.

[Conan-Kudo]

One point seems important to me, which is that in this use case many students can connect (via LDAP or Active Directory for example) to the same station over the course of weeks and months. Permanent authorization should therefore not be given at the user level, but at the machine level, regardless of who is connecting to it.

Both types need to be supported. I could easily see this being useful for other, more prosaic cases, such as remembering when a user authorized an app for screenshots/screencasts, etc.

[jadahl]

This is a topic I've been thinking about a few times, and also believe it is something we need to address. Some questions to answer are:

1. What portals need to be able to handle pre-authorization, and in what fashion?
2. Do the pre-authorization configuration format need to be cross-portal backend? Or does it need to be? Or does it need not to be?
3. Can it be limited to be only configurable by the sysadmin (i.e. only read configuration in e.g. /usr or /etc)?

One use case that I've had in mind is mass installed managed system where IT support must be able to remote control and view the system running the portals to fix issues etc.

@Conan-Kudo can you expand exactly what scenarios Veyon needs pre-authorization?

[jexposit]

Another use case for pre-authorization is CI/CD using a tool like gnome-ponytail-daemon.

On X11, XTest is available to perform automated testing. However, on Wayland we need to use the remote desktop API + libei to emulate user input.

At the moment, gnome-ponytail-daemon is using Mutter's remote desktop API instead of the portal API, but having pre-authorization would make it possible to migrate to the portal API making the tool more portable.

Can it be limited to be only configurable by the sysadmin (i.e. only read configuration in e.g. /usr or /etc)?

You know the internals of xdg-desktop-portal better than me, so I'm not going to try to answer questions 1 and 2. About 3, it looks like an approach that would work for CI/CD.

[idoric]

@jadahl As a system administrator in a school establishment, I have had to install and configure both NetSupport School and Veyon over the years, so I will try to answer your question "can you expand exactly what scenarios Veyon needs pre-authorization?".

You have to imagine a room full of identical computers for the students, plus another computer (different or not) for the teacher. Veyon must be installed on all computers, but only the teacher's computer has the Veyon Master application. As all the student stations are identical, a disk image is created with the addition of Veyon configured correctly, then this image is deployed on all the stations (except obviously that of the teacher). Then any student can connect to any station (via LDAP or AD), and it is very likely that a particular student will not have the same station in each session (student documents are stored on an intranet.). No matter who is connected, the teacher must be able to see and control each station.

Here we are first talking about students in primary school or middle school, there is no question of asking them for authorization to have the right to display their screen or take control of "their" computer from the teacher's computer. This is why the Veyon installed on each student station requires pre-authorization. (Note that the Veyon of a student station will not communicate with any station on which there is a Veyon Master application, it requires authentication, for example via a set of public/private keys, via LDAP or even AD.)

[Conan-Kudo]

Do the pre-authorization configuration format need to be cross-portal backend? Or does it need to be? Or does it need not to be?

This needs to work regardless of used backend. The backends should not have the ability to block pre-authorization by the user or sysadmin.

[GeorgesStavracas]

Duplicate of #759