[opensuse] display managers, startx
I may have missed the story, and google didn't help (perhaps I used the wrong incantation) Questions: 1) Is the *only* reason for deprecating `startx(1)` the setuid bit requirement? If not, what are the other reasons? 2) I have various xset, xrdb and other commands in my ~/.xinitrc prior to the exec of the windowmanager. In the display manager scenario, are these still run? If not, what is the recommended way to have them executed? I wonder if this is the right idea? https://unix.stackexchange.com/questions/47359/what-is-xsession-for and moving the commands from ~/.xinitrc to ~/.xsession? I suppose the exact spot is DM-dependent? FWIW, I use fvwm2, specified in ~/.xinitrc: ``` export WINDOMANAGER=/usr/bin/fvwm ... various xset, xrdb, etc.. commands ... exec $WINDOWMANAGER ${1+"$@"} ``` 3) If I want to swap LightDM for SDDM, what is the recommended procedure? TIA. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/4/18 6:17 PM, Michael Fischer wrote:
2) I have various xset, xrdb and other commands in my ~/.xinitrc prior to the exec of the windowmanager. In the display manager scenario, are these still run? If not, what is the recommended way to have them executed?
I wonder if this is the right idea?
https://unix.stackexchange.com/questions/47359/what-is-xsession-for
and moving the commands from ~/.xinitrc to ~/.xsession? I suppose the exact spot is DM-dependent?
FWIW, I use fvwm2, specified in ~/.xinitrc:
``` export WINDOMANAGER=/usr/bin/fvwm ... various xset, xrdb, etc.. commands ... exec $WINDOWMANAGER ${1+"$@"} ```
I'm using openbox since many years. I'm having the following in my .xinitrc right before the final exec: ( sleep 3 # allow openbox to start before the following. xsetroot -solid black gkrellm -w & root-tail -g 1000x400+100+50 -font fixed /var/log/firewall,red,'ALERT ' /var/log/messages,green & setxkbmap -layout us,de -variant ,nodeadkeys -option grp:rwin_toggle,grp_led:scroll ) & Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Nov 05, Bernhard Voelker wrote:
On 11/4/18 6:17 PM, Michael Fischer wrote:
2) I have various xset, xrdb and other commands in my ~/.xinitrc prior to the exec of the windowmanager. In the display manager scenario, are these still run? If not, what is the recommended way to have them executed?
I wonder if this is the right idea?
https://unix.stackexchange.com/questions/47359/what-is-xsession-for
and moving the commands from ~/.xinitrc to ~/.xsession? I suppose the exact spot is DM-dependent?
FWIW, I use fvwm2, specified in ~/.xinitrc:
``` export WINDOMANAGER=/usr/bin/fvwm ... various xset, xrdb, etc.. commands ... exec $WINDOWMANAGER ${1+"$@"} ```
I'm using openbox since many years. I'm having the following in my .xinitrc right before the final exec:
( sleep 3 # allow openbox to start before the following. xsetroot -solid black gkrellm -w & root-tail -g 1000x400+100+50 -font fixed /var/log/firewall,red,'ALERT ' /var/log/messages,green & setxkbmap -layout us,de -variant ,nodeadkeys -option grp:rwin_toggle,grp_led:scroll ) &
Have a nice day, Berny
Hi Berny, I guess I should take that as an implicit: "Yes, ~/.xinitrc is executed by the display manager." :) Are you doing the sleep because those are commands (minus the setxkbmap) which need the WM fully up to display properly? Yeah, Openbox is good. If they had a solid pager of their own, I'd consider it for its more "regular" conf files (compared to fvwm). Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/5/18 12:11 AM, Michael Fischer wrote:
On Mon, Nov 05, Bernhard Voelker wrote:
I'm using openbox since many years. I'm having the following in my .xinitrc right before the final exec:
( sleep 3 # allow openbox to start before the following. xsetroot -solid black gkrellm -w & root-tail -g 1000x400+100+50 -font fixed /var/log/firewall,red,'ALERT ' /var/log/messages,green & setxkbmap -layout us,de -variant ,nodeadkeys -option grp:rwin_toggle,grp_led:scroll ) &
I guess I should take that as an implicit: "Yes, ~/.xinitrc is executed by the display manager." :)
yes, obviously. ;-)
Are you doing the sleep because those are commands (minus the setxkbmap) which need the WM fully up to display properly?
AFAIR, I did it because I want to have gkrellm "withdrawn" (-w option), i.e., openbox puts it into the 'dock' area.
Yeah, Openbox is good. If they had a solid pager of their own, I'd consider it for its more "regular" conf files (compared to fvwm).
I don't know exactly what you mean with 'solid pager', but there are a few sibling projects - maybe one of them has it? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2018 18.17, Michael Fischer wrote:
I may have missed the story, and google didn't help (perhaps I used the wrong incantation)
Questions:
1) Is the *only* reason for deprecating `startx(1)` the setuid bit requirement? If not, what are the other reasons?
No, there are other reasons. For one thing, I understand it is little maintained. As a consequence, it lacks certain modern features, like the concept of "seat": the person that seats in front of the computer should have the permission to use sound, the cdrom, external storage devices, etc. The display manager handles giving those permission to the person that logs in, without he needing to belong to the pertinent groups. If a different person logs in, he gets the seat instead, and not the other person - who in traditional usage with groups, he still holds the permissions (normally both would have them). Look, the sound devices: cer@Telcontar:~> l /dev/snd/ total 0 drwxr-xr-x 3 root root 220 Oct 20 10:47 ./ drwxr-xr-x 22 root root 6480 Oct 21 02:35 ../ drwxr-xr-x 2 root root 60 Oct 20 10:47 by-path/ crw-rw----+ 1 root audio 116, 2 Oct 20 10:47 controlC0 crw-rw----+ 1 root audio 116, 7 Oct 20 10:47 hwC0D1 crw-rw----+ 1 root audio 116, 4 Oct 26 12:36 pcmC0D0c crw-rw----+ 1 root audio 116, 3 Oct 28 09:37 pcmC0D0p crw-rw----+ 1 root audio 116, 6 Oct 20 10:48 pcmC0D1c crw-rw----+ 1 root audio 116, 5 Oct 20 10:48 pcmC0D1p crw-rw----+ 1 root audio 116, 1 Oct 20 10:47 seq crw-rw----+ 1 root audio 116, 33 Oct 20 10:47 timer cer@Telcontar:~> See the '+' at the end of the permissions? cer@Telcontar:~> getfacl /dev/snd/controlC0 getfacl: Removing leading '/' from absolute path names # file: dev/snd/controlC0 # owner: root # group: audio user::rw- user:cer:rw- <======= group::rw- mask::rw- other::--- cer@Telcontar:~> My user, 'cer', has been granted extended access attribute. If I switch to the text terminal (ctrl-alt-f1) and log in as root, the extended attributes disappear. If on the graphic session I log on a second simultaneous session as another user, that user gets the acls. If I switch back to the first session, the first user gets the permissions back. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Mon, Nov 05, Carlos E. R. wrote:
On 04/11/2018 18.17, Michael Fischer wrote:
I may have missed the story, and google didn't help (perhaps I used the wrong incantation)
Questions:
1) Is the *only* reason for deprecating `startx(1)` the setuid bit requirement? If not, what are the other reasons?
No, there are other reasons.
For one thing, I understand it is little maintained.
As a consequence, it lacks certain modern features, like the concept of "seat": the person that seats in front of the computer should have the permission to use sound, the cdrom, external storage devices, etc.
The display manager handles giving those permission to the person that logs in, without he needing to belong to the pertinent groups. If a different person logs in, he gets the seat instead, and not the other person - who in traditional usage with groups, he still holds the permissions (normally both would have them).
Look, the sound devices:
cer@Telcontar:~> l /dev/snd/ total 0 drwxr-xr-x 3 root root 220 Oct 20 10:47 ./ drwxr-xr-x 22 root root 6480 Oct 21 02:35 ../ drwxr-xr-x 2 root root 60 Oct 20 10:47 by-path/ crw-rw----+ 1 root audio 116, 2 Oct 20 10:47 controlC0 crw-rw----+ 1 root audio 116, 7 Oct 20 10:47 hwC0D1 crw-rw----+ 1 root audio 116, 4 Oct 26 12:36 pcmC0D0c crw-rw----+ 1 root audio 116, 3 Oct 28 09:37 pcmC0D0p crw-rw----+ 1 root audio 116, 6 Oct 20 10:48 pcmC0D1c crw-rw----+ 1 root audio 116, 5 Oct 20 10:48 pcmC0D1p crw-rw----+ 1 root audio 116, 1 Oct 20 10:47 seq crw-rw----+ 1 root audio 116, 33 Oct 20 10:47 timer cer@Telcontar:~>
See the '+' at the end of the permissions?
cer@Telcontar:~> getfacl /dev/snd/controlC0 getfacl: Removing leading '/' from absolute path names # file: dev/snd/controlC0 # owner: root # group: audio user::rw- user:cer:rw- <======= group::rw- mask::rw- other::---
cer@Telcontar:~>
My user, 'cer', has been granted extended access attribute.
If I switch to the text terminal (ctrl-alt-f1) and log in as root, the extended attributes disappear. If on the graphic session I log on a second simultaneous session as another user, that user gets the acls. If I switch back to the first session, the first user gets the permissions back.
Thank you for the explanation and "demonstration". Heh, I've always (since SuSE 6.0, I think) made adding myself to various groups, e.g. audio, a part of the routine anytime I installed. And more recently, of course, setting the perms on X. The above sort of explains why no one else ever mentions doing these things in the past few years. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/11/2018 13.28, Michael Fischer wrote:
On Mon, Nov 05, Carlos E. R. wrote:
...
Thank you for the explanation and "demonstration". Heh, I've always (since SuSE 6.0, I think) made adding myself to various groups, e.g. audio, a part of the routine anytime I installed. And more recently, of course, setting the perms on X. The above sort of explains why no one else ever mentions doing these things in the past few years.
Welcome :-) Yes, I remember having to add my user to a number of groups so that things would work, and people asking about "I can't open the cdrom!" :-) The current idea is to use startx only for debugging some problems, like nvidia driver issues, not for normal usage because not everything will work out of the box. Possibly startx could be updated to do things better, but nobody has done so. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
participants (3)
-
Bernhard Voelker -
Carlos E. R. -
Michael Fischer