| View previous topic :: View next topic |
| Author |
Message |
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3345
Location: Rasi, Finland
|
 Posted: Thu May 18, 2023 8:49 pm Post subject: |
 |
|
| pietinger wrote: | | szatox wrote: | | I think a better question would be "how is PAM better than the alternative". |
If you want do special operations with your login / when you login, you need pam. Examples:
- Using special hardware for user identification
- Doing additional operations whith login, like decrypting with fscrypt |
I have used PAM to create XDG_RUNTIME_DIRs upon login (and emptying upon last logout) on my seatd (no e?loginds) using setups.
Yeah I could do it without PAM, but PAM makes it quite easy.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri May 19, 2023 6:04 am Post subject: |
|
|
| dmpogo wrote: | | onmy machine xorg-server with elogind flag requires elogind with pam flag |
On my machines, I have xorg[systemd, udev] (with neither pam nor suid), and it just works (for Xorg; for wayland I need seatd instead of systemd and a compositor which supports seatd). As mentioned, I am normally booting from openrc despite using the systemd flag here. So I would expect that if you are using elogind instead of systemd it should work as well. Of course, nothing else on my system has the pam flag, either, so this might be the problem for you.
Or maybe the only reason why it works for me is that my logged in user is in the video group? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Fri May 19, 2023 6:25 am Post subject: |
|
|
| mike155 wrote: | The average user: I don't know what it's for and how it works. But it's about security. Therefore, it must be good! Let's install it!
The security expert: More code means less security. If there's no specific reason to install PAM and if you don't understand how it works: don't install it. |
The person who receives the call in the middle of the night: You take on-call responsibility and let's see how quickly that change is reverted to "standard."
And never mind that promotion you're seeking, no, we should not integrate LDAP or AD.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri May 19, 2023 6:36 am Post subject: |
|
|
| Zucca wrote: | I have used PAM to create XDG_RUNTIME_DIRs upon login (and emptying upon last logout) on my seatd (no e?loginds) using setups.
Yeah I could do it without PAM, but PAM makes it quite easy. |
I create these directories with /etc/tmpfiles.d for all users which might log in. No reason to ever empy them.
Of course, this setup is only possible if you know all users in advance. For other systems, you probably need pam anyway (e.g. because of ldap support or whatever). |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3345
Location: Rasi, Finland
|
| Posted: Fri May 19, 2023 8:04 am Post subject: |
|
|
| mv wrote: | | Of course, this setup is only possible if you know all users in advance. For other systems, you probably need pam anyway (e.g. because of ldap support or whatever). |
I tend to plan my system so that I can just run 'adduser' and things work.
Basically I want to automate things if possible. And PAM is one such tool to help me on that.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1535
Location: South America
|
| Posted: Fri May 19, 2023 7:29 pm Post subject: |
|
|
| mv wrote: | | On my machines, I have xorg[systemd, udev] (with neither pam nor suid), and it just works (for Xorg; [...]). |
I wonder how. The usual reason for Xorg failures in this situations is open() call failures for special files in /dev.
| mv wrote: | | I am normally booting from openrc despite using the systemd flag here. |
So you don't have a logind provider running in that case? You can't run systemd-logind because it wants systemd running as process 1, and you can't have elogind because it conflicts with systemd...
| mv wrote: | | Or maybe the only reason why it works for me is that my logged in user is in the video group? |
Maybe...
_________________
| 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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri May 19, 2023 9:22 pm Post subject: |
|
|
| GDH-gentoo wrote: | | You can't run systemd-logind because it wants systemd running as process 1 |
Apparently, this is not completely true. I cannot run Xorg with sddm[-systemd,-elogind] but I can run it with sddm[systemd,-elogind], so some of the calls to logind must change something in the behavior.
Anyway, since I am practically only running wayland for security reasons, I do not care: Fortunately, the compositor I am using makes use of seat, and of course seatd is doing a much better job than systemd or elogind concerning independency of the boot system. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Fri May 19, 2023 9:55 pm Post subject: |
|
|
| GDH-gentoo wrote: |
| mv wrote: | | Or maybe the only reason why it works for me is that my logged in user is in the video group? |
Maybe... |
I don't think that matters much.
These are all the things that are owned by the video group in /dev
| Code: | crw-rw---- 1 root video 195, 0 Mar 29 23:29 /dev/nvidia0
crw-rw---- 1 root video 195, 255 Mar 29 23:29 /dev/nvidiactl
crw-rw---- 1 root video 195, 254 Mar 29 23:29 /dev/nvidia-modeset
crw-rw---- 1 root video 249, 0 Apr 25 20:17 /dev/nvidia-uvm
crw-rw---- 1 root video 249, 1 Apr 25 20:17 /dev/nvidia-uvm-tools
|
I can start xorg without being in the video group and can also start some games.
GDH-gentoo, is your user in the video group?
_________________
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 |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1535
Location: South America
|
| Posted: Sat May 20, 2023 12:11 am Post subject: |
|
|
| stefan11111 wrote: | | GDH-gentoo, is your user in the video group? |
No. Taking your /dev/nvidia* files as an example, adding my user to the video group would give any process that runs with my user full access to those devices (permissions are rw for members of that group), and that doesn't feel wise. Which is why I'm going to look into this when I have some spare time.
_________________
| 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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat May 20, 2023 1:19 pm Post subject: |
|
|
| GDH-gentoo wrote: | | adding my user to the video group would give any process that runs with my user full access to those devices (permissions are rw for members of that group), and that doesn't feel wise |
Thanks for the discussion. The recommendation to be in the video group is probably at least ~20 years old, so maybe it is not valid anymore:
For X, I never saw any risk in this recommendation, because anybody having access to X has access to all graphics anyway.
But you are right that with the more secure model of wayland, it is no longer a good idea to put the user in the video group.
I put the user now instead to the seat group (and started seatd with -g seat instead of -g video, of course), and it works as well:
wayland but also X still come up as they should.
Note that sddm (the login-manager I am using) is in the video group, still. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Sat May 20, 2023 1:32 pm Post subject: |
|
|
| mv wrote: | | GDH-gentoo wrote: | | adding my user to the video group would give any process that runs with my user full access to those devices (permissions are rw for members of that group), and that doesn't feel wise |
Thanks for the discussion. The recommendation to be in the video group is probably at least ~20 years old, so maybe it is not valid anymore:
For X, I never saw any risk in this recommendation, because anybody having access to X has access to all graphics anyway.
But you are right that with the more secure model of wayland, it is no longer a good idea to put the user in the video group.
I put the user now instead to the seat group (and started seatd with -g seat instead of -g video, of course), and it works as well:
wayland but also X still come up as they should.
Note that sddm (the login-manager I am using) is in the video group, still. |
Here are the groups my user is in:
| Code: | $ groups stefan
audio stefan
|
Things seem fine like 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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat May 20, 2023 2:32 pm Post subject: |
|
|
| stefan11111 wrote: | Here are the groups my user is in:
| Code: | $ groups stefan
audio stefan
|
Things seem fine like this. |
If you do not use seatd, this is probably sufficient. If you use seatd (in contrast to systemd/elogind) as a seat manager, it is rather obvious to me that the logged in user should have access to the seatd socket. Being in an additional group is not a security risk, but quite the opposite an additional security layer in this case, as other users cannot even attempt to talk to seatd. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Sat May 20, 2023 7:15 pm Post subject: |
|
|
| mv wrote: |
If you do not use seatd, this is probably sufficient. If you use seatd (in contrast to systemd/elogind) as a seat manager, it is rather obvious to me that the logged in user should have access to the seatd socket. Being in an additional group is not a security risk, but quite the opposite an additional security layer in this case, as other users cannot even attempt to talk to seatd. |
I do not know much about wayland, but do you really need a seat manager to run it?
As described in this thread I linked before, the only thing xorg needs suid for is to access the tty and the mouse.
All that can be achieved through passing the tty you are logged in to xinit and setgid bits(not root setgid).
Can't the same be done for wayland?
_________________
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 |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Sat May 20, 2023 9:24 pm Post subject: |
|
|
Reporting back on the video group thing.
I couldn't start xorg after rebooting/logging out and back in to the tty.
It appears that xorg needs access to /dev/nvidia0 /dev/nvidiactl /dev/nvidia-modeset.
It has access to them if I give it suid permissions, if I am in the video group or if I give it setgid permissions to the video group.
I don't know if this is a nvidia-only thing.
From the other thread:
| Anon-E-moose wrote: | find /dev -ls |grep video
1544 0 crw-rw---- 1 root video 29, 0 May 20 01:10 /dev/fb0
1540 0 crw-rw---- 1 root video 226, 0 May 20 06:39 /dev/dri/card0
1539 0 crw-rw---- 1 root video 226, 128 May 20 01:10 /dev/dri/renderD128 |
here is what happens on my system:
| Code: | $ ls -lah /dev/fb0
crw-rw---- 1 root root 29, 0 Mar 29 23:29 /dev/fb0 |
| Code: | $ ls -lah /dev/dri
ls: cannot access '/dev/dri': No such file or directory |
As can be seen, the video group is not needed for these.
Maybe someone who doesn't use nvidia hardware can confirm if it is indeed a nvidia-only thing.
Seems like the best thing to do is to keep my user in the video group, as I don't plan to give root access to another app like seatd to manage this just so I am in less groups.
_________________
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 |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1535
Location: South America
|
| Posted: Sun May 21, 2023 2:56 am Post subject: |
|
|
| mv wrote: | | GDH-gentoo wrote: | | You can't run systemd-logind because it wants systemd running as process 1 |
Apparently, this is not completely true. I cannot run Xorg with sddm[-systemd,-elogind] but I can run it with sddm[systemd,-elogind], so some of the calls to logind must change something in the behavior. |
I don't know what's going on there. There's several places in systemd-logind's code where messages are sent to well-know bus name org.freedesktop.systemd1 on the system-wide message bus... which is requested by systemd's PID 1 program. So there should be many failures if systemd-logind is somehow running and systemd isn't.
| mv wrote: | | For X, I never saw any risk in this recommendation, because anybody having access to X has access to all graphics anyway. |
Do you mean X11 clients that run as unprivileged processes? Barring undiscovered Xorg bugs that allow exploits, supposedly they can only do what the X protocol allows. I haven't thought about this in detail, is that comparable to having raw access to hardware devices?
| mv wrote: | | Note that sddm (the login-manager I am using) is in the video group, still. |
Normally, OpenRC runs the sddm program as root, and sddm spawns an Xorg child that also runs as root. Is this different on your systems?
_________________
| 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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun May 21, 2023 5:11 am Post subject: |
|
|
| GDH-gentoo wrote: | | mv wrote: | | Note that sddm (the login-manager I am using) is in the video group, still. |
Normally, OpenRC runs the sddm program as root, and sddm spawns an Xorg child that also runs as root. Is this different on your systems? |
I haven't changed any defaults here, neither for openrc nor for systemd, and as mentioned it works with both. I agree that it is very likely sddm runs as root, so maybe sddm can be removed from the video group (I think the ebuild put it there, that's why I kept it). However, I know for sure that the wayland session scripts (which e.g. eventually run the wayland compositor) are run only with user privileges; I'd be surprised if it would be different for the X session scripts. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun May 21, 2023 5:26 pm Post subject: |
|
|
| mv wrote: | | GDH-gentoo wrote: | | mv wrote: | | Note that sddm (the login-manager I am using) is in the video group, still. |
Normally, OpenRC runs the sddm program as root, and sddm spawns an Xorg child that also runs as root. Is this different on your systems? |
I haven't changed any defaults here, neither for openrc nor for systemd, and as mentioned it works with both. I agree that it is very likely sddm runs as root, so maybe sddm can be removed from the video group (I think the ebuild put it there, that's why I kept it). However, I know for sure that the wayland session scripts (which e.g. eventually run the wayland compositor) are run only with user privileges; I'd be surprised if it would be different for the X session scripts. |
I checked now the permissions with htop while running X or wayland with sddm:
It turns out that sddm indeed starts the X server with root permissions, though the window manager runs only with user permissions; the window manager process is a child of some sddm-helper which runs with root permissoins.
For wayland, the compositor is run only with user permissions. The process is as well a child of sddm-helper which runs with root permission. |
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
