#1609 [selinux-policy] gnome-remote-desktop system login feature is disallowed in enforcing mode | rhbz#2271661
Closed by blockerbot. Opened by blockerbot.

Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2271661 **
Information from BlockerBugs App:
2271661

Current vote summary

Commented but haven't voted yet: catanzaro, mrkspflr

The votes have been last counted at 2024-08-19 15:57 UTC and the last processed comment was #comment-925573

To learn how to vote, see:
https://pagure.io/fedora-qa/blocker-review
A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)


I was aware of this during F40 but didn't propose it because I believed that no release criterion applies to it. @catanzaro mentions default app functionality and system settings is included in them, but the remote login option seems really niche (also disabled by default) and it doesn't feel "basic" to me. Also, Workstation WG specifically asked us to consider "basic functionality" a bare minimum.

We could also consider this criterion:

Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops.

But again, this criterion was written with a local login in mind, and remote login is not even enabled by default. So currently I feel like

FinalBlocker -1

I'm not opposed to blocking on it, but I think that an explicit new criterion for remote login would be needed here. @catanzaro are you interested in proposing one?

Hm, you have a point.

I was actually thinking "default panel functionality" (since this is a broken desktop feature, not a broken application), but that's probably too much of a stretch since it's certainly not part of the panel.

FinalBlocker -1

as the remote connection, or remote login, have been always a little bit unreliable and one had to try different solutions to make it happen which is possible in the end.

On the other hand, I believe that this feature should be there and it should be strong, especially on a Linux desktop.

Hey there :-)

sorry for my critisism but after .. 2weeks .. of "OMG we got a usable RDP feature OOBE on the Linux horizon...."

  • the current implementation of gnome-remote-desktop.service is totally unusable IRL imho.

  • Long time Fedora user here (or maybe it's better to say... since ..pre.. KDE1 / RH Linux 6.1 cartman)

  • at first when this feature was announced it REALLY looked promising but (seemingly not only..) for the ordinary desktop user it might be easier to ignore all the "oh-yeah-we're-GNOME and it's caused by your SELinux (which we .. btw .. unfortunately still also ship with unusable presets for in regards to an usable smb rdp oobe... ) ... or your wayland vs X11 setup and generally your fault to post this in the incorrect forums locations... " before acknowledging that a modern OS nowadays should have functional toggles for features the developers advertise, regardless if showstopper or not, but it does not have this currently.

so imho for the ordinary F40 user in 2024 it would be easier

  • either install guacamole on a bastion / jumpserver for allthings vnc and ssh and rdp and split the daily driver's desktop environment into two or more physical systems...

or maybe it would be an easier way for everyone to

  • just implement a rdp plugin for cockpit.

current situation ihmo:

ordinary users can install cockpit -> add a cert in the correct folder -> it's functional.

vs

ordinary users activate the toggle in gnome-remote-desktop.service GUI integration -> it doesn't work seemingly due to SELinux enforce vs permissive -> user has to spend three hours of finding out how to set SELinux into permissive mode (which nobody wants permanently IRL nowadays..) -> user wastes 14days of electrical energy entering things into search machines just to find out that the feature shipped ++6months ago is not even avlbl in alpha quality -> could be related to wayland/mutter too -> finds out that to enable the feature correctly the shipped freerdp libs maybe have to be patched blaaaaaaa -> has to mess around with SELinux -> has to mess around with NTLM_NEGOTIATE_blaaaa entries in logfiles just to find the reason WHY it is not working out of the box as it should.

maybe it really would be better to move the functionality into a cockpit plugin... (?) or keep on using ssh on linux in 2024?

As the criteria stand:
FinalBlocker -1
we can have a discussion about making this explicitly part of the criteria, but I think that should happen after it already works.

AGREED RejectedFinalBlocker

The following votes have been closed:

Metadata Update from @blockerbot:
- Issue status updated to: Closed (was: Open)

Release F41 is no longer tracked by BlockerBugs, closing this ticket.

Log in to comment on this ticket.

Metadata