Re: [blfs-dev] elogind X build order
On Thu, Oct 03, 2019 at 08:35:37PM +0100, Ken Moffat via blfs-dev wrote:
> On Wed, Oct 02, 2019 at 09:53:21PM -0500, Douglas R. Reno wrote:
> >
> > https://ch1p.io/blog/1/ (WARNING: The Security Certificate expired on 10/1.
> > The site and the links within (attached) are safe.)
> > https://stackoverflow.com/questions/29708596/drmdropmaster-requires-root-privileges
> > https://github.com/gch1p/drm_master_util
> > https://f.ch1p.io/fnHHUx0b/rootless_modesetting_1.20.3.patch
> >
> > From what I gather, the patch puts a call out over a file descriptor and
> > socket to spawn a suid wrapper indirectly, which only affects AMD cards. I'm
> > not 100% sure if my interpretation is correct though, since this is all so
> > complex...
> >
> > - Doug
>
> I'll be trying this later (as well as fixing up my build)
> The hack is actually for Xorg's own modesetting driver, but if it
> also fixes things for ati/amdgpu then all will be good.
>
I'm attaching a headed version of the patch: AFAICS it is less
dangerous than the alternative of running X as root in the old way.
I can just dump this in patches/ but I'd like to mention it on the
xorg-server page for use on the server's own modesetting driver as
well as (most) radeon and amdgpu chipsets. The original post in the
debian bug I pointed to suggested that for at least one chipset,
with the wrapper debian used to use for non-systemd, rootless xorg
worked - but not for others.
It seems to me that this is better than running Xorg itself with
root privileges.
Comments, please.
ĸen
--
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
- Unseen Academicals
Not Yet Submitted By: Ken Moffat
Date: 2019-10-04
Initial Package Version: 1.20.3
Upstream Status: Unknown
Origin: Evgeny Zinoviev, https://github.com/gch1p/drm_master_util
Description: A workaround for rootless xorg using the server's
modesetting driver, also useful on many ati/radeon and amdgpu
chipsets if systemd is not used (they use different code paths
than intel and nouveau). A few ati/amdgpu chipsets might not need
this.
>From the notes at https://ch1p.io/blog/1/
(Using rootless Xorg without systemd works with the intel driver,
but not with Xorg's own modesetting) :
This is because drmSetMaster and drmDropMaster require root privileges.
So in order to make it work we have to hack Xorg and make it call these
functions under root.
How about we write a suid helper program that will receive a file
descriptor, call the desired function and exit? Sounds like a very dirty
hack, but hey, it's better than the whole X server running under root.
So here's how it's gonna work. Instead of just calling drmSetMaster(ms->fd),
the X server will create a new UNIX domain socket and wait for a connection.
At the same time it'll launch our siud helper program from another thread.
The helper program will connect to that socket. The X server will accept the
connection and write ms->fd to the socket. The helper program will read the fd,
call drmSetMaster (or drmDropMaster) and exit. The X server will then close the
socket and continue execution as normally.
(Note by Ken: the alternative is to create /etc/X11/Xwrapper.config with the
line:
needs_root_rights = yes
That will cause Xorg to run with root privileges.)
diff --git a/hw/xfree86/drivers/modesetting/driver.c
b/hw/xfree86/drivers/modesetting/driver.c
index 8d29b13..1034ef9 100644
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -34,6 +34,11 @@
#endif
#include
+#include
+#include
+#include
+#include
+#include
#include
#include "xf86.h"
#include "xf86Priv.h"
@@ -62,6 +67,8 @@
#include "driver.h"
+#define DRM_HACK_SOCKET_NAME "xorg_drm_master_util"
+
static void AdjustFrame(ScrnInfoPtr pScrn, int x, int y);
static Bool CloseScreen(ScreenPtr pScreen);
static Bool EnterVT(ScrnInfoPtr pScrn);
@@ -1513,11 +1520,66 @@ msSharedPixmapNotifyDamage(PixmapPtr ppix)
return ret;
}
+static int
+send_fd(int sock, int fd)
+{
+// This function does the arcane magic for sending
+// file descriptors over unix domain sockets
+struct msghdr msg;
+struct iovec iov[1];
+struct cmsghdr *cmsg = NULL;
+char ctrl_buf[CMSG_SPACE(sizeof(int))];
+char data[1];
+
+memset(&msg, 0, sizeof(struct msghdr));
+memset(ctrl_buf, 0, CMSG_SPACE(sizeof(int)));
+
+data[0] = ' ';
+iov[0].iov_base = data;
+iov[0].iov_len = sizeof(data);
+
+msg.msg_name = NULL;
+msg.msg_namelen = 0;
+msg.msg_iov = iov;
+msg.msg_iovlen = 1;
+msg.msg_controllen = CMSG_SPACE(sizeof(int));
+msg.msg_control = ctrl_buf;
+
+cmsg = CMSG_FIRSTHDR(&msg);
+cmsg->cmsg_level = SOL_SOCKET;
+cmsg->cmsg_type = SCM_RIGHTS;
+cmsg->cmsg_len = CMSG_LEN(sizeof(int));
+
+*((int *) CMSG_DATA(cmsg)) = fd;
+
+return sendmsg(sock, &msg, 0);
+}
+
+static void*
+thread_func(vo
Re: [blfs-dev] Name for the localed daemon
On 10/3/19 1:56 PM, Pierre Labastie via blfs-dev wrote: I'm going to try to become "upstream" for the standalone localed daemon. I think I'll take the openrc implementation rather than systemd, because systemd's implementation relies on a big utility library. Before doing anything, I need to choose a name. Of course, elocaled comes to mind, but adding "e" is some king of gentoo mark. Since it would be a blfs project, I'd rather use something else. What about blocaled (with b as in blfs, or Bruce, or build)? Other possibilities: plocaled (with p as in Pierre JK), salocaled (with sa for standalone)... I was thinking blocaled. The problem with svlogind like Bruce said is that it implies that it's designed for SysV systems only. It's primarily designed for use in BLFS if I'm not mistaken, but similar to elogind, might be adopted elsewhere. blocaled fits best in my opinion. "BLFS localed" has a nice ring to it :-) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind X build order
On Thu, Oct 03, 2019 at 08:30:38PM +0100, Ken Moffat via blfs-dev wrote: > On Thu, Oct 03, 2019 at 09:17:03AM +0200, Pierre Labastie via blfs-dev wrote: > > On 03/10/2019 02:48, Ken Moffat via blfs-dev wrote: > > > [...] > > > > > > Thanks, I'm inclined to bellieve that I'm barking up the wrong tree. > > > > > > My current xorg-server build configures and runs make as user lfs, > > > because I eventually discovered that my normal build-as-root was > > > forcing suid install. So now I have > > > > > > su lfs -c "./configure --prefix=/usr --sysconfdir=/etc > > > --localstatedir=/var \ > > > --with-xkb-output=/var/lib/xkb \ > > > --enable-glamor \ > > > --enable-suid-wrapper \ > > > --disable-systemd-logind \ > > > > Hmmm, I see something suspicious here. Don't we need logind? > > We do not have this line in the book. > > > Arghh! To quote Snoopy: "Rats!" > > Probably a significant part of the story on intel machines. > With that change (on top of building all of the extra xcb-util packages, no idea if those are really needed), with a kernel that started from defconfig, PLUS the patch Doug pointed to, rootless Xorg is now working. A big Thank You to everyone who has commented on the various threads. I'll reply to Doug's thread about the patch in a moment. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Name for the localed daemon
On 10/3/19 4:27 PM, Tim Tassonis via blfs-dev wrote: On 10/3/19 10:50 PM, Pierre Labastie via blfs-dev wrote: On 03/10/2019 21:45, Bruce Dubbs via blfs-dev wrote: On 10/3/19 1:56 PM, Pierre Labastie via blfs-dev wrote: I'm going to try to become "upstream" for the standalone localed daemon. I think I'll take the openrc implementation rather than systemd, because systemd's implementation relies on a big utility library. Before doing anything, I need to choose a name. Of course, elocaled comes to mind, but adding "e" is some king of gentoo mark. Since it would be a blfs project, I'd rather use something else. What about blocaled (with b as in blfs, or Bruce, or build)? Other possibilities: plocaled (with p as in Pierre JK), salocaled (with sa for standalone)... sv_localed? As in System V. Well, it should be compatible with other init systems as well (runit for example), or rather completely independent on the init system. It's a standalone daemon, which is started by dbus on demand, and which only depends on some almost standard configuration files. How about ulocaled then, with the u standing for unix. llocaled would be another idea, l for linux. Or nlocaled. Not systemd-localed. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Name for the localed daemon
On 10/3/19 10:50 PM, Pierre Labastie via blfs-dev wrote: On 03/10/2019 21:45, Bruce Dubbs via blfs-dev wrote: On 10/3/19 1:56 PM, Pierre Labastie via blfs-dev wrote: I'm going to try to become "upstream" for the standalone localed daemon. I think I'll take the openrc implementation rather than systemd, because systemd's implementation relies on a big utility library. Before doing anything, I need to choose a name. Of course, elocaled comes to mind, but adding "e" is some king of gentoo mark. Since it would be a blfs project, I'd rather use something else. What about blocaled (with b as in blfs, or Bruce, or build)? Other possibilities: plocaled (with p as in Pierre JK), salocaled (with sa for standalone)... sv_localed? As in System V. Well, it should be compatible with other init systems as well (runit for example), or rather completely independent on the init system. It's a standalone daemon, which is started by dbus on demand, and which only depends on some almost standard configuration files. How about ulocaled then, with the u standing for unix. llocaled would be another idea, l for linux. Tim -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Name for the localed daemon
On 03/10/2019 21:45, Bruce Dubbs via blfs-dev wrote: > On 10/3/19 1:56 PM, Pierre Labastie via blfs-dev wrote: >> I'm going to try to become "upstream" for the standalone localed >> daemon. I think I'll take the openrc implementation rather than >> systemd, because systemd's implementation relies on a big utility >> library. >> >> Before doing anything, I need to choose a name. Of course, elocaled >> comes to mind, but adding "e" is some king of gentoo mark. Since it >> would be a blfs project, I'd rather use something else. What about >> blocaled (with b as in blfs, or Bruce, or build)? Other possibilities: >> plocaled (with p as in Pierre JK), salocaled (with sa for >> standalone)... > > sv_localed? As in System V. > Well, it should be compatible with other init systems as well (runit for example), or rather completely independent on the init system. It's a standalone daemon, which is started by dbus on demand, and which only depends on some almost standard configuration files. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Name for the localed daemon
On 10/3/19 1:56 PM, Pierre Labastie via blfs-dev wrote: I'm going to try to become "upstream" for the standalone localed daemon. I think I'll take the openrc implementation rather than systemd, because systemd's implementation relies on a big utility library. Before doing anything, I need to choose a name. Of course, elocaled comes to mind, but adding "e" is some king of gentoo mark. Since it would be a blfs project, I'd rather use something else. What about blocaled (with b as in blfs, or Bruce, or build)? Other possibilities: plocaled (with p as in Pierre JK), salocaled (with sa for standalone)... sv_localed? As in System V. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind X build order
On Thu, Oct 03, 2019 at 09:17:03AM +0200, Pierre Labastie via blfs-dev wrote: > On 03/10/2019 02:48, Ken Moffat via blfs-dev wrote: > > [...] > > > > Thanks, I'm inclined to bellieve that I'm barking up the wrong tree. > > > > My current xorg-server build configures and runs make as user lfs, > > because I eventually discovered that my normal build-as-root was > > forcing suid install. So now I have > > > > su lfs -c "./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var > > \ > > --with-xkb-output=/var/lib/xkb \ > > --enable-glamor \ > > --enable-suid-wrapper \ > > --disable-systemd-logind \ > > Hmmm, I see something suspicious here. Don't we need logind? > We do not have this line in the book. Arghh! To quote Snoopy: "Rats!" Probably a significant part of the story on intel machines. > > > --disable-install-setuid \ > > We have removed --enable-install-setuid, so I think disable is the default, > but this shouldn't hurt. > > Pierre It was a preliminary step towards trying to disable the suid install when configure was run as root, but did not work. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind X build order
On Wed, Oct 02, 2019 at 09:53:21PM -0500, Douglas R. Reno wrote: > > Good evening folks > > I found the following things out while looking online for solutions to this > problem earlier. It seems to be due to the way that permissions are handled > on card0, since AMDGPU/ATI drivers need access to a kernel function that is > only available if you are root. The Intel and Nouveau drivers don't use > modesetting in the way that AMD/ATI cards do. > > https://ch1p.io/blog/1/ (WARNING: The Security Certificate expired on 10/1. > The site and the links within (attached) are safe.) > https://stackoverflow.com/questions/29708596/drmdropmaster-requires-root-privileges > https://github.com/gch1p/drm_master_util > https://f.ch1p.io/fnHHUx0b/rootless_modesetting_1.20.3.patch > > From what I gather, the patch puts a call out over a file descriptor and > socket to spawn a suid wrapper indirectly, which only affects AMD cards. I'm > not 100% sure if my interpretation is correct though, since this is all so > complex... > > - Doug I'll be trying this later (as well as fixing up my build) - at the moment the picasso is ploughing on through my normal desktop packages, and the machine with the R600 is about to be testing some new DRAM. The hack is actually for Xorg's own modesetting driver, but if it also fixes things for ati/amdgpu then all will be good. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Name for the localed daemon
I'm going to try to become "upstream" for the standalone localed daemon. I think I'll take the openrc implementation rather than systemd, because systemd's implementation relies on a big utility library. Before doing anything, I need to choose a name. Of course, elocaled comes to mind, but adding "e" is some king of gentoo mark. Since it would be a blfs project, I'd rather use something else. What about blocaled (with b as in blfs, or Bruce, or build)? Other possibilities: plocaled (with p as in Pierre JK), salocaled (with sa for standalone)... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] fcron
On 10/3/19 8:31 AM, Maurice van der Stee via blfs-dev wrote: Hello, fcron has a configuration parameter to set the pid directory. Setting this to /run fixes the systemd service file so the fix for that is not needed. Good morning / afternoon, Thanks for reporting this! I'll drop that in my next commit, it's much more elegant than the sed that we were using to accomplish that task. It's much cleaner as well. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] fcron
Hello, fcron has a configuration parameter to set the pid directory. Setting this to /run fixes the systemd service file so the fix for that is not needed. -- === Maurice van der Stee (s...@planet.nl) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind X build order
On 03/10/2019 02:48, Ken Moffat via blfs-dev wrote: > [...] > > Thanks, I'm inclined to bellieve that I'm barking up the wrong tree. > > My current xorg-server build configures and runs make as user lfs, > because I eventually discovered that my normal build-as-root was > forcing suid install. So now I have > > su lfs -c "./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ > --with-xkb-output=/var/lib/xkb \ > --enable-glamor \ > --enable-suid-wrapper \ > --disable-systemd-logind \ Hmmm, I see something suspicious here. Don't we need logind? We do not have this line in the book. > --disable-install-setuid \ We have removed --enable-install-setuid, so I think disable is the default, but this shouldn't hurt. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
