Grafisch programma draaien onder "su"

[Josefien]

Mijn vraag
...
Onder Ubuntu MATE/Lubuntu is het iets wat altijd out-of-the-box werkt: een grafisch programma bijv. "pcmanfm-qt" aanroepen met root-rechten in een terminal-venster d.m.v. "su".

In Debian werkt dit echter niet, krijg de volgende foutmelding:

code:

root@ws46:~# pcmanfm-qt
qt.qpa.screen: QXcbConnection: Could not connect to display 
Could not connect to any X display.

Hoe krijg ik het ook onder Debian werkend?

Via een omweg als in een ssh-server installeren, root-login toestaan en dan met "ssh -X root@localhost" verbinding maken met de lokale ssh-server kan ik wèl grafische programma's draaien met root-rechten. Echter, heb ik liever dat het direct onder "su" werkt i.p.v. een lokale ssh-verbinding opzetten met X-forwarding...


Relevante software en hardware die ik gebruik
...
- Debian Linux 10
- QTerminal
- LXQT desktop


Wat ik al gevonden of geprobeerd heb
...
Na wat Google'en zou de volgende regel...

code:

session         optional        pam_xauth.so

...toevoegen aan /etc/pam.d/su moeten helpen.

Dat is echter niet het geval, het veranderd de foutmelding alleen maar:

code:

root@ws46:~# pcmanfm-qt
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

[jan99999]

In ubuntu is dit volgens mij pas veranderd.

In ubuntu mate hoef je niet met su te werken.
Via grafische programma kan dit gewoon, zeker voor de gewone gebruiker is dit gemakkelijker.
Via de de verkenner(caja in mate), kun je dmv rechts klik op map/file, dan openen als admin, of openen in de terminal.

Voor je debian heb ik geen antwoord.

[Jrz]

Probeer

code:

su -

om je environment mee te nemen. Wellicht dat hij niet weet waar je X draait.

[BoAC]

En gksudo is ook weg. Heb er even op gezocht en vond deze: https://forum.ubuntu-nl.o...074.msg1020803#msg1020803

Dan kom ik uit op:

code:

pkexec gedit

Dit werkt echter niet omdat de Display niet bekend is.
Echter lukt dit wel:

code:

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit

Overigens, dit is nog onder Ubuntu..

Komt echter de hamvraag: waarom zou je dit willen?

[ Voor 10% gewijzigd door BoAC op 01-12-2020 07:24 ]

[Josefien]

Jrz schreef op dinsdag 1 december 2020 @ 07:11:
Probeer

code:

su -

om je environment mee te nemen. Wellicht dat hij niet weet waar je X draait.

Dat maakt geen verschil.

BoAC schreef op dinsdag 1 december 2020 @ 07:22:
En gksudo is ook weg. Heb er even op gezocht en vond deze: https://forum.ubuntu-nl.o...074.msg1020803#msg1020803

Dan kom ik uit op:

code:

pkexec gedit

Dit werkt echter niet omdat de Display niet bekend is.
Echter lukt dit wel:

code:

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit

Overigens, dit is nog onder Ubuntu..

Komt echter de hamvraag: waarom zou je dit willen?

Onder Debian werkt pkexec ook niet. Er komt wel een grafische pop-up die vraagt een het root-password, maar daarna gebeurt er niks behalve deze foutmelding:

code:

josefien@ws46:~$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY pcmanfm-qt
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

Waarom ik dat zou willen? Om bijv. een bestand aan te passen/te vervangen in één v/d systeemmappen? In een grafische file-manager is dan veel makkelijker/sneller dan alle paden uittikken in de command-line.

Of een programma als Unetbootin willen gebruiken wat root-rechten nodig heeft.

[Hero of Time]

Geen su gebruiken, maar gewoon sudo. Zeker als je met X-forwarding over SSH werkt. Wanneer je namelijk 'su' gebruikt, verander je werkelijk van gebruiker, standaard root. En die heeft geen variabelen of 'authenticatie' voor je grafische mogelijkheden. Er zijn omwegen, maar die vereisen meer werk dan simpelweg 'sudo' te gebruiken.

Het is hierbij wel vereist dat zowel sudo is geïnstalleerd als dat de gebruiker waarmee je dit gebruikt ook echt sudo mag uitvoeren. Als je een root wachtwoord hebt opgegeven tijdens de installatie van Debian, zal sudo niet aanwezig zijn en moet je dit zelf installeren en configureren (middels visudo, of je gebruiker aan de 'sudo' groep toevoegen).

Houd er ook rekening mee dat grafische programma's tegenwoordig kieskeurig kunnen zijn als ze met root rechten worden gestart. Je zal dan een alternatief moeten gebruiken die hier niet over klaagt.

[AlterEgo]

Je hebt een custom action nodig m.b.v. policykit.
https://unix.stackexchang...s-as-root-by-using-pkexec

[Josefien]

Hero of Time schreef op dinsdag 1 december 2020 @ 17:52:
Geen su gebruiken, maar gewoon sudo. Zeker als je met X-forwarding over SSH werkt. Wanneer je namelijk 'su' gebruikt, verander je werkelijk van gebruiker, standaard root. En die heeft geen variabelen of 'authenticatie' voor je grafische mogelijkheden. Er zijn omwegen, maar die vereisen meer werk dan simpelweg 'sudo' te gebruiken.

Het is hierbij wel vereist dat zowel sudo is geïnstalleerd als dat de gebruiker waarmee je dit gebruikt ook echt sudo mag uitvoeren. Als je een root wachtwoord hebt opgegeven tijdens de installatie van Debian, zal sudo niet aanwezig zijn en moet je dit zelf installeren en configureren (middels visudo, of je gebruiker aan de 'sudo' groep toevoegen).

Houd er ook rekening mee dat grafische programma's tegenwoordig kieskeurig kunnen zijn als ze met root rechten worden gestart. Je zal dan een alternatief moeten gebruiken die hier niet over klaagt.

Ik wil geen sudo gebruiken juist omdat ik daarvoor gebruikers lokaal toe moet voegen. Terwijl ik het vanuit in principe elke (via LDAP ingelogde) gebruiker wil kunnen.

En ik wil juist geen SSH gebruiken, maar dat is nu de enige manier om onder Debian een grafische applicatie als root uit te voeren... namelijk SSH'en naar de lokale ssh-server... "ssh -X root@localhost"

De bedoeling is eigenlijk dat het werkt zoals onder Ubuntu: "su -" en dan alle grafische programma's kunnen uitvoeren die draaien onder root ondersteunt.

AlterEgo schreef op dinsdag 1 december 2020 @ 20:06:
Je hebt een custom action nodig m.b.v. policykit.
https://unix.stackexchang...s-as-root-by-using-pkexec

Maar da's per programma en niet 1x instellen en alles programma's werken onder "su"?

Moet ik dus als ik een keer bijv. Unetbootin heb gedownload weer een policykit-bestand nodig? Dat was nooit nodig geweest in Ubuntu en om eerlijk te zijn wel erg veel extra werk.

[JaQ]

Huh? Iedere user die inlogt via ldap zal toch wel een gemeenschappelijke groep hebben? Die groep mag ook in ldap staan. (En daar kan je vervolgens je sudo rule aan hangen)

[AlterEgo]

Josefien schreef op dinsdag 1 december 2020 @ 22:46:
[...]
Maar da's per programma en niet 1x instellen en alles programma's werken onder "su"?

Moet ik dus als ik een keer bijv. Unetbootin heb gedownload weer een policykit-bestand nodig? Dat was nooit nodig geweest in Ubuntu en om eerlijk te zijn wel erg veel extra werk.

Ja, dat moet je per programma doen. Ik weet geen andere manier.

Maar zo heel erg is dat niet. Ik gebruik er twee: één om als root een file manager te kunnen starten, en één om een root console te kunnen openen. Vanuit de root console kan ik grafische programma's opstarten als root.

[Hero of Time]

Josefien schreef op dinsdag 1 december 2020 @ 22:46:
[...]

Ik wil geen sudo gebruiken juist omdat ik daarvoor gebruikers lokaal toe moet voegen. Terwijl ik het vanuit in principe elke (via LDAP ingelogde) gebruiker wil kunnen.

Zoals hierboven al is gezegd, daar zijn andere oplossingen voor. Bij mij op 't werk zijn er ook een paar Linux gebruikers en die zitten in een aparte groep zodat ze sudo kunnen gebruiken. Die groep heb ik in de sudoers gezet (kan ook als los bestand in /etc/sudoers.d, maar als daar een fout in zit, zal sudo niet meer werken totdat dat is hersteld omdat er geen validatie op gedaan wordt bij het plaatsen/opslaan).

Afhankelijk van de LDAP koppeling (is dat OpenLDAP, MS Active Directory, anders...) zou je al in de configuratie daarvan sudo regels kunnen maken. Bijvoorbeeld door iedereen toe te staan sudo uit te voeren, waardoor je niet nog eens apart de sudoers hoeft aan te passen.

En ik wil juist geen SSH gebruiken, maar dat is nu de enige manier om onder Debian een grafische applicatie als root uit te voeren... namelijk SSH'en naar de lokale ssh-server... "ssh -X root@localhost"

Dat was mij niet helemaal duidelijk, omdat je het telkens over ssh had. Lokaal zou prima moeten werken via 'sudo <commando voor grafisch programma>'. Tenzij uiteraard het programma zelf weigert te draaien met root rechten, zoals gedit en kate (editors van Gnome en KDE) of Dolphin en waarschijnlijk ook Nautilus (file managers van KDE en Gnome).

De bedoeling is eigenlijk dat het werkt zoals onder Ubuntu: "su -" en dan alle grafische programma's kunnen uitvoeren die draaien onder root ondersteunt.

Ubuntu doet vaak extra config of 'patches' om zulk soort dingen te laten werken. Ik verwacht overigens niet dat 'su -' standaard werkt op Ubuntu, want er is geen wachtwoord op de root gebruiker en is daardoor uitgeschakeld. Het lijkt mij ook ongewenst om iedereen maar het wachtwoord voor root te geven, wanneer ze ook net zo goed met hun eigen wachtwoord uit de voeten kunnen.

[Josefien]

De LDAP-server is een OpenLDAP, beheert via een web-interface phpldapadmin. Deze wordt ook gebruikt door Ubuntu-cliënts dus er mogen geen wijzigingen in worden aangemaakt die het gedrag daar kunnen beïnvloeden.

De pcmanfm-qt file-manager heeft geen problemen met onder root te draaien, immers werkt het ook via ssh en als er met root grafisch wordt ingelogd, er staat alleen een waarschuwing "root instance" onder.

Het klopt dat su standaard niet werkt onder Ubuntu, maar da's heel simpel op te lossen door "sudo su" => passwd en dan een password instellen. Daarna werken grafische programma's automatisch.

Ik blijf het raar vinden dat voor zoiets simpels blijkbaar geen simpele oplossing bestaat terwijl het elders standaard werkt

[psike_ch]

Ik heb in een oeroud draadje op linuxquestions een paar oplossingen gevonden.
https://www.linuxquestion...un-x-apps-as-root-205533/

Ik heb de "xhost +localhost" lokaal geprobeerd, en dat werkt bij mij op debian 10.

[delphium]

Allereerst, Debian geeft niet voor niets een waarschuwing! Ik kan zo ook geen reden bedenken waarom je een GUI-programma als root zou willen draaien, want dat is ook gewoon een heel slecht idee.

Als je dat toch wilt doen onder Debian kan je het volgende doen:

code:

su
export DISPLAY=:1
gimp

Als dat niet werkt kun je als normale user kijken wat je display is met:

code:

echo $DISPLAY

Maar nogmaals, waarom zou je programma's als root willen draaien?

[ Voor 0% gewijzigd door delphium op 07-12-2020 14:49 . Reden: typfoutje ]

[Hero of Time]

@delphium, wat maakt het precies uit? Ik open Thunar ook wel eens als root. Dit doe ik dan als ik m'n package archive cache wil opruimen, maar niet alles wil weggooien via 'apt clean'.

Zo zou je ook kunnen bedenken dat gebruikers van de TS bepaalde config willen aanpassen door bestanden te bewerken, maar de terminal editors niet prettig vinden. Dan is de editor als root draaien wel zo handig, iets wat dan automatisch gebeurt als je de file manager met root rechten opent (dat helpt dan ook gelijk tegen de 'permission denied' meldingen als je de map opent waar die bestanden in staan).

[delphium]

@Hero of Time

Debian (maar ook veel andere distro's) gebruiken sudo. De reden daarvoor is dat met sudo:

• Niet alle users het rootwachtwoord hoeven te weten
• Gewone gebruikers niet zomaar alle commando's (als root) kunnen uitvoeren

Zeker op een multi-user-systeem (wat @Josefien gebruikt begrijp ik, want LDAP) is dat wel een dingetje.
Distro's hebben nou eenmaal bepaalde ontwerpkeuzes al gemaakt. Als je daar vervolgens met je eigen systeemontwerp tegenin gaat, kan dat op den duur grote problemen opleveren met de veiligheid van je systeem, of zelfs je hele netwerk.

Op een single-user-systeem is het uiteraard weer heel anders, maar ook daar zou ik de Debian way volgen met sudo.

@Josefien, volgens mij kun je sudo ook configureren met LDAP. Wellicht is dat een oplossing voor je.

[Josefien]

Ik wil geen sudo gebruiken Los van extra configuratie en het niet standaard werken onder elke gebruiker moet ik ook bij elk commando dat sudo ervoor zetten.

Overigens lijkt er een specifiek probleem met pcmanfm-qt te zijn. Want met export DISPLAY=:0 werkt het ook niet. Maar andere programma's zoals featherpad tekst-editor werkt wel... Terwijl pcmanfm-qt wèl werkt via een ssh -X root@localhost

[GuntherDW]

Josefien schreef op zaterdag 12 december 2020 @ 22:52:
Ik wil geen sudo gebruiken Los van extra configuratie en het niet standaard werken onder elke gebruiker moet ik ook bij elk commando dat sudo ervoor zetten.

Je kan ook gewoon een "shell" starten dmv "sudo -s" hoor, hoe je niet constant voor elk commando "sudo" te zetten.
Al komt dat natuurlijk met dezelfde gevaren als gewoon alles onder "su" draaien.

Met sudo heb je dan wel het voordeel dat je kan instellen dat je enviro variables worden overgenomen, dus ook je $DISPLAY etc.

[Hero of Time]

Josefien schreef op zaterdag 12 december 2020 @ 22:52:
Ik wil geen sudo gebruiken Los van extra configuratie en het niet standaard werken onder elke gebruiker moet ik ook bij elk commando dat sudo ervoor zetten.

Laat men dan direct inloggen met root. En zet je firewall uit. En wachtwoorden, wat is dat? Gooi gewoon alle beveiliging het raam uit, want waarom zou je daar ook maar iets mee willen doen?

Wat je wilt is terug naar de jaren '90 en Windows gebruiken, waar alles en iedereen alles mocht en beveiliging een vervelend concept was dat alleen maar in de weg zit.

Overigens lijkt er een specifiek probleem met pcmanfm-qt te zijn. Want met export DISPLAY=:0 werkt het ook niet. Maar andere programma's zoals featherpad tekst-editor werkt wel... Terwijl pcmanfm-qt wèl werkt via een ssh -X root@localhost

Dat komt omdat je wat hier aangegeven wordt letterlijk probeert uit te voeren. En dat gaat fout, want je moet toch eerst even controleren of wat je wilt, ook echt klopt. Is je $DISPLAY ook echt ':0', of toch iets anders?


Met je vraag om in principe elke vorm van security te slopen, vraag ik mij af of wij jou wel verder moeten helpen. Ik zie er namelijk al van komen dat er een topic komt met vragen waarom sommige zaken opeens niet meer werken.

[CAPSLOCK2000]

Ik zie een paar problemen door elkaar lopen. Laat ik met de kritische vragen beginnen, het is hier wel Tweakers

Wat probeer je te bereiken?
Ik snap dat je die filemanger als root wil draaien, maar waarom? Wil je gebruikers echt volledige rechten geven over dit systeem? Als ze die filemanager als root mogen draaien kunnen ze iedere file op dat systeem aanpassen en ieder commando op dat systeem als root uitvoeren. Als je ze toch al zoveel rechten wil geven dan zou je ze ook echt als root kunnen laten inloggen.
Is hetzelfde niet te bereiken door de juiste rechten/ACLs op de bestanden te zetten die moeten worden aangepast?

Maar goed, laat ik er even van uit gaan dat je er goed over na hebt gedacht en dat dit echte de beste aanpak is.
Dan zie ik een paar losse problemen om aan te pakken.
1. Draait software als root zonder 'sudo' prefix
2. Geef software die als root draait toegang tot de X-server van de gebruiker.
3. Zorg dat pcmanfm-qt fatsoenlijk opstart.

1.
De old-school oplossing is 'setuid'. Dit wordt tegenwoordig gezien als zeer onwenselijk omdat het alles of niets is.
# chmod 4701 /usr/local/bin/mijnapp

Een modernere oplossing zijn Linux Capabilities. Daarmee kun je veel gerichter speciale rechten toekennen aan gewone gebruikers, zodat die bv wel het netwerk kunnen herconfigureren maar niks anders.
Zoek naar "Linux Capabalities" en zie bv https://man7.org/linux/man-pages/man1/capsh.1.html

Als je bezwaar echt is tegen het zelf invoeren van 'sudo' kun je ook nog een kleine wrapper maken:

#!/bin/sh
sudo /usr/local/bin/myapp.real

2. Zie xauth . Dat is de nette manier om gebruikers (inclusief root) toegang te geven tot elkaars X sessie.
In je poging met pexec maak je hier al gebruik van.

3. Hier heb ik geen idee waarom het nog niet werkt. Op grond van die foutmelding denk ik dat het X-deel van het probleem is opgelost en dat er nu iets anders dwars zit. Ik zou zelf beginnen met goed te kijken naar alle environment variabelen (via 'export') maar ik weet natuurlijk ook niet of het probleem echt daar zit.

[ Voor 3% gewijzigd door CAPSLOCK2000 op 13-12-2020 12:31 ]

[Josefien]

De wens is simpel, namelijk zodra ik het nodig heb de file manager als root kunnen uitvoeren, ongeacht welk account er momenteel is ingelogd. Ik ben de enige met root-wachtwoord.

Hero of Time schreef op zondag 13 december 2020 @ 12:17:
[...]

Dat komt omdat je wat hier aangegeven wordt letterlijk probeert uit te voeren. En dat gaat fout, want je moet toch eerst even controleren of wat je wilt, ook echt klopt. Is je $DISPLAY ook echt ':0', of toch iets anders?

Nee, in het voorbeeld staat een "1". Ik heb juist gecheckt wat het op mijn systeem is en er een "0" van gemaakt.

Verder is su willen gebruiken helemaal niet hetzelfde als alle beveiliging uitzetten. Ik ben de enige die het root-wachtwoord heeft en wil simpelweg ongeacht het ingelogd account of machine root-rechten kunnen gebruiken.

Je kunt onder Debian 10 trouwens niet eens dmesg bekijken als niet-root.

[Schnupperpuppe]

Verder is su willen gebruiken helemaal niet hetzelfde als alle beveiliging uitzetten. Ik ben de enige die het root-wachtwoord heeft

Oh nee? Geef mij een file-manager met root-rechten en jij bent je root-wachtwoord kwijt hoor ;-)

Edit: Ik denk dat ik je opmerking verkeerd had geïnterpreteerd...
Je wilt dus niet dat iedere gebruiker zonder wachtwoord een file-manager met root-rechten kan opstarten. Alleen jijzelf met het root-wachtwoord?

[ Voor 32% gewijzigd door Schnupperpuppe op 13-12-2020 13:17 ]

[delphium]

@Josefien Kun je misschien in een iets bredere context vertellen om wat voor situatie het gaat? Je gebruikt LDAP, wat doet vermoeden dat er meerdere gebruikers op het systeem zijn. Vervolgens zeg je dat jij de enige bent die het rootwachtwoord heeft. Dan zeg je dat je ongeacht welk account is ingelogd, je root rechten wilt. gebruik jij zelf meerdere accounts? Waarom precies? en waarom met LDAP? Is dit een werkomgeving, of voor thuis? Zoals @CAPSLOCK2000 als vraagt: "Wat wil je precies bereiken"?

Je kunt onder Debian 10 trouwens niet eens dmesg bekijken als niet-root.

Waarom denk je dat dat zo is? Omdat de mensen bij Debian geen idee hebben waar ze mee bezig zijn?

[Josefien]

De computers staan thuis. Op een enkel exemplaar komen andere gebruikers voor. Voor de rest heb ik zelf meerdere accounts. LDAP omdat ik op elk systeem hetzelfde account wil hebben. Tot voor kort ook /home op nfs.

Dit veranderd de situatie echter niet, die blijft namelijk "onder su grafische programma's willen uitvoeren incl. de file manager zoals onder Ubuntu 16.04 ook kon". En ik ben de enige die dat wil/nodig heeft op een systeem, niet alle mogelijke gebruikers.

Geen dmesg onder niet-root is trouwens opgelost door "kernel.dmesg_restrict=0" toe te voegen aan /etc/sysctl.conf.

[ Voor 7% gewijzigd door Josefien op 14-12-2020 19:29 ]