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

[Hans de Goede]

Hi,

On 01/22/2014 11:41 AM, Peter Hutterer wrote:
> 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?

Hmm, a good point, no syslog is not signal-handler safe, see:
http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2004-02/0285.html

The BSD-s have a syslog_r which does not have this issue, but for some
reason this has never been added to glibc.

So I guess using syslog is of the table.

Regardsm

Hans