[PATCH 0/3] linux: Allow console switching to work without root rights

[Peter Hutterer]

On 22/01/2014 18:40 , Hans de Goede wrote:
> Hi,
>
> On 01/22/2014 03:17 AM, Peter Hutterer wrote:
>> On Tue, Jan 21, 2014 at 09:47:31AM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> 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 ?

hmm, I swear I typed the answer to this but: yes, upstreaming it is a 
good idea (though I haven't looked at the patch in detail)

>>>>> 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
>>> /var/log/messages
>>
>> 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
> configuration.

fair enough. syslog can filter on priority but right now most of our log 
file is rather a mess. we have a two-step logging system (type + 
priority) but most parts of the server just use default verbosity, hence 
the massive log file where everything that could be interesting to see 
is dumped. Filtering will be relatively unsuccessful until the various 
messages are audited and I'm not sure this can easily be done.
but maybe that's a nonissue anyway, do people care about a 500-line log 
dump every time the server starts up?

that's the same when it's on stdout of course (well, worse, since you 
can't filter at all). the question would then be if we go all the way 
and add systemd journald support directly? Alan, would syslog change 
anything for you?

>
> , 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.

regarding the API there is a potential pitfall: the actual print path 
must be safe to be called from signal handler. Is the syslog API safe 
for that?

Cheers,
   Peter

>>> 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
>> well.
>
> 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.
>
> Regards,
>
> Hans