[PATCH 0/3] linux: Allow console switching to work without root rights
Hans de Goede
hdegoede at redhat.com
Wed Jan 22 00:40:55 PST 2014
On 01/22/2014 03:17 AM, Peter Hutterer wrote:
> On Tue, Jan 21, 2014 at 09:47:31AM +0100, Hans de Goede wrote:
>> On 01/21/2014 05:44 AM, Peter Hutterer wrote:
>>> On Thu, Jan 16, 2014 at 11:24:48AM +0100, Hans de Goede wrote:
>>>> This patch-set makes it possible to run without as non-root without
>>>> -sharevts. With the caveat that the user must specify the vt from which X is
>>>> started as the vt to run on (as both gdm and startx do by default).
>>> I think for startx that's a fedora patch, I don't think that's upstream.
>> So maybe we should upstream it ?
Any input on this bit ?
>>>> With this patch-set + my systemd-logind patches I can login as user on a vt,
>>>> and do startx without needing a suid-root bit on my xserver.
>>>> There are only 2 minor issues left with running as non root after this:
>>>> 1) One (harmless) error message about failing to get iopl rights
>>>> 2) Currently my /var/log is writable by the user as which I start x
>>>> Solving 1) is something to do after I've figured out how we want to deal
>>>> with UMS when the xserver is not suid root
>>>> For 2), I'm thinking about just logging to the users home dir, so user hans
>>>> would get a /home/hans/.Xorg.0.log file. Input on this is much appreciated.
>>> I'd be tempted to even skip logging to a file and log to stdout only. That
>>> way whatever launches X can decide how to handle the log output,
>>> specifically with a few minor changes in gdm we could make sure the output
>>> ends up in the journal.
>> If we want to integrate nicely with the journal the easiest way would be to
>> just use syslog. But some people are going to dislike xorg spamming their
> yeah, our log is a bit too verbose at the moment. syslog forces output to
> the syslog
I assume you mean to syslogd, well not really, not in a systemd world,
where everything will be intercepted by journald first, and on ie new default
Fedora installs, there is no syslogd at all.
But you're right that if there is a syslogd, even with journalctl it will get
all messages, although those can typically be filtered out with syslogd
, by printing to stdout we leave the policy of where it goes up to
> the caller, i.e. the DM in the vast majority of the cases. and especially in
> this particular case where we need some integration beyond "run Xorg on the
> commandline" anyway.
The advantage of syslogd is that is contains a log-level, which is useful
to filter for, if we log to stdout we loose this info and we cannot tell
journalctl to ie only show warnings and errors.
The syslog API was designed for logging, and with journald things will
end up in the journal anyways (no matter if we use syslog or stdout), so
lets try to get as much useful meta-data in the journal together with the
message as possible, which means using syslog.
>> So maybe add syslog support + an option for selecting whether to use file
>> based logging or syslog + a ./configure option to set the default (file
>> or syslog) ?
> I was thinking of a simple Xorg -nologfile to disable the log file. That
> should be simple enough to add. I suspect we could get the same result right
> now with -logfile /dev/null.
I realize that using syslog will be a slightly more invasive patch, but I
believe it is the right thing to do. And yes we will need to put it behind
a runtime config flag, otherwise we will get lots of flames from people who
want things to keep working the old way.
>> And in the file case of /var/log/.... fails fall back to ~/.Xorg.#.log ?
> how about $XDG_DATA_HOME/xorg/Xorg.#.log? That has a defined default as
I wanted to lookup in the xdg spec what the proper xdg path would be, but
I see you've already done that for me :) Yes that would be even better.
More information about the xorg-devel