Vergeten te vermelden tijdens 't lanceerfeestje van openSUSE 12.2: als je LXDE installeert als werkomgeving, en je wil een terminal met rootrecht hebben om daarin bepaalde grafische progjes te starten (zoals Beaver of Leafpad, om configuratiebestanden handmatig te bewerken), dan heb je niks aan
su -
. Wat wel kan is
su -p
Uitleg:
https://sites.google.com/site/computertip/opensuse#TOC-Enkele-tips-voor-de-LXDE-werkomgeving
(rechterkolom, punt 16 b)
Hm, een merkwaardige optie. De man pagina zegt::
-p
same as -m
Verhelderend 
Dus lezen we:
-m, --preserve-environment
do not reset environment variables
Voor mij is nu onduidliiejk wat er gebeurt. Je hebt niet -l, dus geen login shell. En dat wil volgens mij al zeggen dat je environmnet gehandhaafd blijft. En wat doet de combinatie -l -m? Raadsels.
En dus is het moeilijk aan te geven wat de veiligheidsgevolgen van het gebruik van -m (-p) al dan niet samen met -l (-) zijn.
Als ik tijd heb, ga ik mischien testen 
Voor zover ik het weet, verdraagt LXDE het niet dat binnen de sessie van de ene gebruiker ook environment variables van een andere worden geladen. Dat doe je met " su -". Voor zover ik het me kan herinneren (heb daar jaren geleden eens iets over gelezen in de mailinglists) default op de meeste distros nu " su " naar “su -m”, d.w.z. de environment variables van de gebruiker die " su " of " su -m " uitvoert worden gehandhaafd. Ik kan me, denkend aan waarom LXDE gemaakt is, daar iets bij voorstellen.
Tijdens één van mijn experimenten heb ik ook gemerkt dat LXDE het niet fijn vindt als er ook nog ergens een KDE of GNOME sessie draait. Schermcorruptie etc. Maar, bedacht ik ook toen, LXDE is niet gemaakt om dit soort dingen te kunnen.
[QUOTE][Voor zover ik het weet, verdraagt LXDE het niet dat binnen de sessie van de ene gebruiker ook environment variables van een andere worden geladen. Dat doe je met " su -"./QUOTE]
Technisch snap ik hier niets van. Environment variabelen zijn niet terug te voeren op een gebruiker. Ze staan in de environment van een proces. En een kind proces erft ze. Als dat kind proces su is en je hebt de *-l *optie opgegeven worden ze weggegooid en wordt een login shell gestart, die zelf (defaults, .profile van de nieuwe gebruiker, …) toevoert aan zijn environment en dus daarna doorgeeft aan zijn kinderen (ingetikte commandos).
Ik kan mij voorstellen dat die ingetikte (LXDE) commandos nu variabelen mist die in de oorspronkelijke GUI aanswezig waren. En dan dus moeilijk doet.
Hetzelfde geldt bijv ook voor de DISPLAY variabele, die in de oorspronkelijk GUI is gezet, maar in de nieuw gestartte terminal sessie niet. Aanroepen van ieder GUI programma gaat dan dus fout. Niet alleen in LXDE.
[QUOTE=hcvv;2493673]
[Voor zover ik het weet, verdraagt LXDE het niet dat binnen de sessie van de ene gebruiker ook environment variables van een andere worden geladen. Dat doe je met " su -"./QUOTE]
Technisch snap ik hier niets van. Environment variabelen zijn niet terug te voeren op een gebruiker. Ze staan in de environment van een proces. En een kind proces erft ze. Als dat kind proces su is en je hebt de *-l *optie opgegeven worden ze weggegooid en wordt een login shell gestart, die zelf (defaults, .profile van de nieuwe gebruiker, …) toevoert aan zijn environment en dus daarna doorgeeft aan zijn kinderen (ingetikte commandos).Ik kan mij voorstellen dat die ingetikte (LXDE) commandos nu variabelen mist die in de oorspronkelijke GUI aanswezig waren. En dan dus moeilijk doet.
Hetzelfde geldt bijv ook voor de DISPLAY variabele, die in de oorspronkelijk GUI is gezet, maar in de nieuw gestartte terminal sessie niet. Aanroepen van ieder GUI programma gaat dan dus fout. Niet alleen in LXDE.
Probeer het volgende eens terwijl je onder KDE werkt
su -
(password invullen)
systemsettings
en vergelijk dat met
su
(password invullen)
systemsettings
en met
su -m
(password invullen)
systemsettings
dan zul je zien dat er verschil is tussen “su -” enerzijds en “su” of “su -m” anderzijds. Als je daarna in LXDE inlogt, zul je zien dat “su” werkt, maar “su -” niet.
Dat er verschil is tussen *su -l *enerzijds en su anderzijds is mij heel erg duidelijk. Maar wat is het onderscheid tussen su -m en su? Hmm, luiheid terzijde en gezocht. De info file geef meer info 
Dus in Konqueror:
info:/coreutils/su invocation
of in een terminal
info coreutils 'su invocation'
En dan zie je waar precies het verschilk zit tussen su en su -m.
Blijft voor mij de vraag of in het LXDE geval su niet goed werkt en *su -m *wel. Maar dat is een beetje academisch.
Ik vind het lastig om te bepalen, of “su -p” (oftewel “su -m”) de beste keuze is in LXDE, nu “su -” afvalt… Beter dan “su”, lijkt me, maar meer kan ik er niet van zeggen. Kunnen jullie dat wel?
Ik denk dat je gelijk hebt.
In ieder geval zou ik *su -p/m * alleen gebruiken voor die dingen waar het anders niet gaat (zoals hier bepaalde statements in LXDE). Dan zo snel mogelijk exit (zoals altijd al). En eventuele andere zaken weer met su -.
Ik ben onder UNIX trouwens groot gebracht met het gebruiken van
su -c ' what_you_want_to_do_with_root_permissions '
en gebruik dat meestal, de laatste tijd ook wel kdesu.
Wat ik heel eigenaardig vind in het hele verhaal is het volgende, ontdekt tijdens mijn experimenten om meer gevoel bij de materie te krijgen.
Op mijn laptop bestaan 2 gebruikers, user_1 en user_2. Ik wil dolphin draaien met de permissies van user_2, terwijl ik ingelogd ben als user_1.
Als ik
su user_2
doe, krijg ik de melding dat de sessie bus niet gevonden wordt, en ik
export $(dbus-launch)
uit moet voeren. Nadat ik dat gedaan heb, start dolphin keurig op, met de instellingen van user_2
Maar als ik het volgende doe:
su -m user_2
doe, krijg ik een foutmeldingen, over het niet schrijfbaar zijn van bestanden/mappen in /home/user_1. Dat zou in mijn ogen betekenen, dat bij het gebruik van " su -m " ook de $HOME wordt meegenomen. Wat mij bij het runnen van commando’s met root rechten niet de bedoeling lijkt, omdat zo ook configuratiebestanden met root rechten worden gewijzigd. Mijns inziens heeft root daar zijn eigen home voor in /root.