Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
non-root xorg static /dev
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sat Mar 25, 2023 8:40 pm    Post subject: Reply with quote

NeddySeagoon wrote:
stefan11111

Code:
ls /dev/input/m* -l
crw------- 1 root root 13,  63 Nov  4  2021 /dev/input/mice
is what I have. 606 lets anyone read and write /dev/input/mice

A better solution may be to make it crw-rw---- 1 root video.
You will be in the video group anyway, for accelerated graphics. If you wanted finer grain control of access to hardware devices you could create a new group, or several if that helped.

Code:
$ ls /dev/tty -l
crw-rw-rw- 1 root root 5, 0 Mar 19 19:34 /dev/tty


-- edit --
From that Mar 19 date, its not what was originally there. Something remade it at that time.

I did chown root:input /dev/input/mice and chmod 660 /dev/input/mice and everything worked.
I am both in the video group and in the input group.
I also applied these things to that /dev/snd script to make it more secure. You can see the updated version here:
https://github.com/stefan11111/config-files/blob/main/mknod_snd
Is doing things this way more/less secure than the suid way?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54317
Location: 56N 3W

PostPosted: Sat Mar 25, 2023 8:45 pm    Post subject: Reply with quote

stefan11111,

You have security against threats, without knowing the treats you want to guard against, the question cannot be answered.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sat Mar 25, 2023 8:57 pm    Post subject: Reply with quote

NeddySeagoon wrote:
stefan11111,

You have security against threats, without knowing the treats you want to guard against, the question cannot be answered.

The treat I want to guard against is programs being exploited and taking advantage of this.
I'm mostly concerned about librewolf, since it's a browser and a huge target for bad actors.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1549
Location: South America

PostPosted: Sat Mar 25, 2023 9:07 pm    Post subject: Reply with quote

stefan11111 wrote:
I am both in the video group and in the input group.
[...]
Is doing things this way more/less secure than the suid way?

You are giving every program that runs on your computer with your user as its effective user full access to several hardware devices, so they can do whatever they want with them. Many people might argue that you are making your attack surface larger...

Keyloggers will probably love that your user is a member of the input and tty groups...
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Ionen wrote:
As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though :)
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sat Mar 25, 2023 9:21 pm    Post subject: Reply with quote

GDH-gentoo wrote:
stefan11111 wrote:
I am both in the video group and in the input group.
[...]
Is doing things this way more/less secure than the suid way?

You are giving every program that runs on your computer with your user as its effective user full access to several hardware devices, so they can do whatever they want with them. Many people might argue that you are making your attack surface larger...

Keyloggers will probably love that your user is a member of the input and tty groups...

Just ran chown root:video /dev/input/mice and removed my user from the input group.
If I remove my user from the tty group, I can't start xorg at all.
Code:
$ groups stefan
tty audio video stefan

What groups are you in?

EDIT
Seems like chown root:video /dev/tty0 and chown root:video /dev/tty7 allow me to start xorg without being in the tty group, but it likely makes little difference.
When I log in, /dev/tty1 gets owner stefan:tty. Shouldn't this be used when I start xorg with --vt1?
I also seems like starting xorg with startx --vt1 does nothing.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1549
Location: South America

PostPosted: Sat Mar 25, 2023 10:13 pm    Post subject: Reply with quote

stefan11111 wrote:
What groups are you in?

I only made my unprivileged user a member of wheel and portage. No groups associated with hardware devices. But I use either SDDM —which spawns an Xorg child that runs as root—, or startx and elogind. And also use systemd-udevd, so I have libudev and thus can use xf86-input-evdev as the input driver.

If I had no elogind and a static /dev, though, I would just go with a suid Xorg, like NeddySeagoon.
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Ionen wrote:
As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though :)
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sat Mar 25, 2023 11:12 pm    Post subject: Reply with quote

Looks like I was just using startx wrong.
Its
Code:
startx -- vt1

not
Code:
startx --vt1

I have this in my .bashrc to automatically set this on any tty:
Code:
alias startx="startx -- vt$(tty | sed -e 's|/dev/tty||')"

Using this allows me to not have my user in the tty group, while having all the /dev/tty* belong to root:tty, except the one I'm logged into, which belongs to stefan:tty.
From what I can see, It's either have /dev/input/mice belong to a group that I'm a part of, or I set the suid bit on xorg.
But is this any more dangerous than what I'm using for /dev/snd?
And why does the keyboard work without any of this, while the mouse doesn't?
And how can any of these be practically exploited?
For some reason, the wiki and a news item all advise against suid.
If SDDM spawns your xorg as root, don't you get a lot of gui apps screaming at you because you launch them as root?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1549
Location: South America

PostPosted: Sun Mar 26, 2023 1:28 am    Post subject: Reply with quote

stefan11111 wrote:
And why does the keyboard work without any of this, while the mouse doesn't?

Different special files involved. xf86-input-keyboard uses the /dev/ttyn file that Xorg already opened. xf86-input-mouse needs to open the special file named in the Device option of the corresponding InputDevice section in xorg.conf. /dev/input/mice in this case. Both require privileges in general, except the /dev/ttyn file in the special case in which you tell Xorg to open the one that is owned by you.

stefan11111 wrote:
For some reason, the wiki and a news item all advise against suid.

Already addressed in previous posts of this thread.

stefan11111 wrote:
If SDDM spawns your xorg as root, don't you get a lot of gui apps screaming at you because you launch them as root?

Xorg runs as root, not the GUI applications. Those run as separate processes, have the effective user ID of the (unprivileged) user that logged in with SDDM, and don't interact with hardware devices. They are X clients, they communicate with the X server, which does that on their behalf.
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Ionen wrote:
As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though :)
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 8:40 am    Post subject: Reply with quote

Yet another way of getting this to work is:
Code:

# groupadd xorg
# chmod 2711 /usr/bin/Xorg
# chown root:xorg /usr/bin/Xorg
# chown root:xorg /dev/input/mice

From my understanding, this only gives Xorg permissions over the files owned by group xorg, which in this case is only /dev/input/mice and no longer gives my user permission over that file.
It this better than both solutions?
This no longer gives acces to /dev/input/mice to the programs I start.
This doesn't give Xorg full root privileges.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54317
Location: 56N 3W

PostPosted: Sun Mar 26, 2023 9:29 am    Post subject: Reply with quote

stefan11111,

It all comes back to the threat you trying to defend against.
If the threat can't happen to you there is nothing to defend against as the problem cannot be turned into an attack.

In your own case ... what is the problem with running xorg suid?

Here, I'm the only user. That makes many potential vulnerabilities irrelevant.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 9:40 am    Post subject: Reply with quote

NeddySeagoon wrote:
stefan11111,

It all comes back to the threat you trying to defend against.
If the threat can't happen to you there is nothing to defend against as the problem cannot be turned into an attack.

In your own case ... what is the problem with running xorg suid?

Here, I'm the only user. That makes many potential vulnerabilities irrelevant.

Say I visit a malicious website, which exploits a vulnerability in librewolf.
If that vulnerability also allows an attacker to get access to my X session, I would like the damage to be contained and to not give an attacker root access.
I am mostly concerned about something like this
There is also the principle of least privilege.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
Leonardo.b
Apprentice
Apprentice


Joined: 10 Oct 2020
Posts: 299

PostPosted: Sun Mar 26, 2023 11:58 am    Post subject: Reply with quote

An example (old) local exploit:
https://learn.redhat.com/t5/Platform-Linux/An-interesting-local-privilege-escalation-vulnerability-in-Xorg/td-p/2284

I like setgid solution.
Beware upgrades will change /usr/bin/Xorg permissions back to default.

I have one untrusted user, a sandbox user.
Running X with high privileges seems unnecessary to me, as long as the fix is cheap I don't see why using suid.

Then, everyone use case is different.
Your world your rules.
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 12:41 pm    Post subject: Reply with quote

Leonardo.b wrote:
An example (old) local exploit:
https://learn.redhat.com/t5/Platform-Linux/An-interesting-local-privilege-escalation-vulnerability-in-Xorg/td-p/2284

I have one untrusted user, a sandbox user.
Running X with high privileges seems unnecessary to me, as long as the fix is cheap I don't see why using suid.

Then, everyone use case is different.
Your world your rules.

Seems like this exploit doesn't work even with suid xorg, mush less with mine.
I also wrote my own su and I can toggle empty password support at build time.
https://github.com/stefan11111/su
Leonardo.b wrote:

I like setgid solution.
Beware upgrades will change /usr/bin/Xorg permissions back to default.

It seems like it is the time to learn ebuilds, or just set permissions after every update.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3151

PostPosted: Sun Mar 26, 2023 1:41 pm    Post subject: Reply with quote

Quote:
It seems like it is the time to learn ebuilds, or just set permissions after every update.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/Advanced#Hooking_into_the_emerge_process

You're welcome
Back to top
View user's profile Send private message
Jimmy Jazz
Guru
Guru


Joined: 04 Oct 2004
Posts: 330
Location: Strasbourg

PostPosted: Sun Mar 26, 2023 2:27 pm    Post subject: Reply with quote

what about sys-auth/seatd instead elogind ? There is an ebuild for it.
Also setpriv and the right capabilities could help too. I was unable to make it work with lightdm (X runs but the display stays black) :(
_________________
« La seule condition au triomphe du mal, c'est l'inaction des gens de bien » E.Burke
Code:

+----+----+----+
|    |::::|    |
|    |::::|    |
+----+----+----+

motto: WeLCRO
WritE Less Code, Repeat Often
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1549
Location: South America

PostPosted: Sun Mar 26, 2023 2:43 pm    Post subject: Reply with quote

NeddySeagoon wrote:
In your own case ... what is the problem with running xorg suid?
Leonardo.b wrote:
Running X with high privileges seems unnecessary to me, as long as the fix is cheap I don't see why using suid.

Worth repeating: in my opinion, the killer argument against worrying too much about Xorg's privileges are display managers. For instance, every KDE user here is very likely running SDDM, so if they are in X11 mode, they are already running Xorg as root, perhaps not even noticing, whatever the permissions of the Xorg binary are.
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Ionen wrote:
As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though :)
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 2:58 pm    Post subject: Reply with quote

GDH-gentoo wrote:
NeddySeagoon wrote:
In your own case ... what is the problem with running xorg suid?
Leonardo.b wrote:
Running X with high privileges seems unnecessary to me, as long as the fix is cheap I don't see why using suid.

Worth repeating: in my opinion, the killer argument against worrying too much about Xorg's privileges are display managers. For instance, every KDE user here is very likely running SDDM, so if they are in X11 mode, they are already running Xorg as root, perhaps not even noticing, whatever the permissions of the Xorg binary are.

Perhaps, but I am running xorg with startx, so it very much does matter to me.
I suspect that a lot of people also start xorg like this too.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1549
Location: South America

PostPosted: Sun Mar 26, 2023 3:00 pm    Post subject: Reply with quote

Jimmy Jazz wrote:
what about sys-auth/seatd instead elogind ? [...] I was unable to make it work with lightdm

It all boils down to what your display manager of choice expects, not what you want to run. If it is expecting to connect to the system-wide message bus and talk to a D-Bus client that implements the org.freedesktop.login1 interface, you are stuck with elogind or seatd with the elogind backend...
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Ionen wrote:
As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though :)
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 3:02 pm    Post subject: Reply with quote

Jimmy Jazz wrote:
what about sys-auth/seatd instead elogind ? There is an ebuild for it.
Also setpriv and the right capabilities could help too. I was unable to make it work with lightdm (X runs but the display stays black) :(

I'd rather log into a tty as root and start X that way instead of trusting another program with this.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 3:26 pm    Post subject: Reply with quote

Do you all have different WM/DE's installed and use a DM to more easily manage them?
Also, aren't seatd and elongid only useful for multi-user machines, where different people would log in at the same time and share resources?
I can't imagine that the average gentoo machine has multiple human users, who each have their own WM/DE.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 3:54 pm    Post subject: Reply with quote

szatox wrote:
Quote:
It seems like it is the time to learn ebuilds, or just set permissions after every update.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/Advanced#Hooking_into_the_emerge_process

You're welcome

Thanks.
I created this file:
Code:
$ cat /etc/portage/env/x11-base/xorg-server
post_pkg_postinst() {
        chown root:xorg /usr/bin/Xorg
        chmod 2711 /usr/bin/Xorg
}

Permissions seem to get properly set.
On another note, can someone tell me why librewolf wants xvfb?
It seems to be related to pgo, but why?
Code:
x11-base/xorg-server:0

  (x11-base/xorg-server-21.1.7:0/21.1.7::gentoo, ebuild scheduled for merge) USE="xorg -debug -elogind -minimal (-selinux) -suid -systemd -test -udev -unwind -xcsecurity -xephyr -xnest -xvfb" ABI_X86="(64)" pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (x11-base/xorg-server-21.1.7:0/21.1.7::gentoo, installed) USE="xorg xvfb -debug -elogind -minimal (-selinux) -suid -systemd -test -udev -unwind -xcsecurity -xephyr -xnest" ABI_X86="(64)" pulled in by
    x11-base/xorg-server[xvfb] required by (www-client/librewolf-111.0_p3:0/111::librewolf, installed) USE="X eme-free gmp-autoupdate hardened lto openh264 pgo pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp -clang -dbus -debug -geckodriver -hwaccel -jack -libproxy -screencast (-selinux) -sndio -system-png -system-python-libs -wayland -wifi" ABI_X86="(64)" L10N="-ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -de -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fur -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -sc -sco -si -sk -sl
-son -sq -sr -sv -szl -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW"

_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 21724

PostPosted: Sun Mar 26, 2023 4:12 pm    Post subject: Reply with quote

How do you propose to collect the profile needed for Profile Guided Optimization of a GUI program if there is no GUI on which to run it? Xvfb is likely used so the program has somewhere to pretend to display itself while collecting the profile.
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1549
Location: South America

PostPosted: Sun Mar 26, 2023 6:42 pm    Post subject: Reply with quote

stefan11111 wrote:
Do you all have different WM/DE's installed and use a DM to more easily manage them?

I can't speak for everybody, but the answer is likely "no". If people are running a desktop environment, X11 window manager or Wayland compositor, it is probably safe to assume that it's because they want to interact with their computer using a GUI, right? A display manager provides you with a graphical login, and controls for initiating shutdown from the graphical login, so you have the GUI experience 100% of the computer's uptime, you never actually see a text user interface other than perhaps the bootloader's.

stefan11111 wrote:
Also, aren't seatd and elongid only useful for multi-user machines, where different people would log in at the same time and share resources?

[GNU/]Linux and the BSDs, like the original UNIX, are multiuser, so GUI software is written by default with support for sessions from multiple users. The fact that it might happen to run on a computer with only one real human user is just a special case. Same as having an operating system with a TCP/IP stack on a computer that happens to not be connected to a network, or with support for IPv6 on a computer that happens to be connected to only IPv4 networks.
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Ionen wrote:
As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though :)
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 7:34 pm    Post subject: Reply with quote

NeddySeagoon,

Can you post the output of a few more commands after running them on your system?
Code:
ls -lah /dev/null
ls -lah /dev/ptmx
ls -lah /dev | grep snd
ls -lah /dev/sr0
ls -lah /dev/rtc0

_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
stefan11111
l33t
l33t


Joined: 29 Jan 2023
Posts: 922
Location: Romania

PostPosted: Sun Mar 26, 2023 7:43 pm    Post subject: Reply with quote

GDH-gentoo wrote:
stefan11111 wrote:
Do you all have different WM/DE's installed and use a DM to more easily manage them?

I can't speak for everybody, but the answer is likely "no". If people are running a desktop environment, X11 window manager or Wayland compositor, it is probably safe to assume that it's because they want to interact with their computer using a GUI, right? A display manager provides you with a graphical login, and controls for initiating shutdown from the graphical login, so you have the GUI experience 100% of the computer's uptime, you never actually see a text user interface other than perhaps the bootloader's.

I don't think the gentoo community is known for liking GUI's and avoiding tty's.
If all you want to do is start X on boot can't you add it to the local service and have it start Xorg, either as root or non-root?

GDH-gentoo wrote:

stefan11111 wrote:
Also, aren't seatd and elongid only useful for multi-user machines, where different people would log in at the same time and share resources?

[GNU/]Linux and the BSDs, like the original UNIX, are multiuser, so GUI software is written by default with support for sessions from multiple users. The fact that it might happen to run on a computer with only one real human user is just a special case. Same as having an operating system with a TCP/IP stack on a computer that happens to not be connected to a network, or with support for IPv6 on a computer that happens to be connected to only IPv4 networks.

Is it good for regular users to give yet another app control over their system when they probably don't need to?
I can't see how seatd/elogind is any better than that setgid stuff.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum