Xorg replaces TTY1

[berenge...@neutralite.org]

Hello.

There is a behavior change I noticed when I switched to Jessie, which
have always annoyed me but that I never tried to resolve.

The change is that now, when I use startx on TTY1, Xorg replaces the
TTY. I understand that it is not a problem for 99% of users, but I would
like to know how to configure Debian to stay with the old behavior (aka:
start Xorg on TTY 7+).
Do someone have any clue about how to do that?

Thanks.

PS: I am not registed on this list, so please CC me.

[Bert Riding]

I too am not a fan of the new behavior. X now runs on the terminal from
which it is started, so to run it on tty7 you must run a getty on tty7 and
log in there first. Do this by editing /etc/inittab (if using init) or
/etc/systemd/logind.conf (if using systemd.)

[berenge...@neutralite.org]

> Until the last month or so it was possible to use "startx -- tty24"
> to
> run X on tty24, accessed by AltGr-F12, for instance. This also no
> longer works. I now have tty24 listed as my ReserveVT in logind.conf
> so that a getty is run there and I can login and then run startx.
>
> There are undoubtedly other ways (like screen, perhaps) to open the
> tty
> you prefer.

I see.

But this trick won't prevent the me to be able to see what X11 print on
screen, right? This is the reason I do not like this behavior.
Like, for example, "/home/foo/.xinitrc: numlockx: not found", "failing
to find font foo, falling back to bar", etc. Those messages that people
not using big DEs can wish to access to (again, I know this is not the
majority).

Also, note that there is absolutely nothing about that in Debian
release notes for Jessie. I tried to find something on the web about it
too, but was never able to find anything relevant. I guess I did not
used the good search terms.

[Felix Miata]

berenge...@neutralite.org composed on 2015-11-22 00:09 (UTC+0100):

> There is a behavior change I noticed when I switched to Jessie, which
> have always annoyed me but that I never tried to resolve.

> The change is that now, when I use startx on TTY1, Xorg replaces the
> TTY. I understand that it is not a problem for 99% of users, but I would
> like to know how to configure Debian to stay with the old behavior (aka:
> start Xorg on TTY 7+).
> Do someone have any clue about how to do that?

I don't know either, and would also like to know. Clues may be that other
distros' behavior changed as well, but in different ways. e.g., one way I
have seen is if login and startx is on vtty3, then X runs on vtty3 (x>x; IIRC
Fedora). Another I've seen is if login and startx is on vtty5, then X runs on
vtty6 (x>x+1). IIRC this change has to do with systemd, but I don't remember
on which distro I saw the x>x+1 behavior to be able to compare
configurations, once configuration can even be found. Possibly is was
LinuxMint or LMDE. Mailing lists xo...@lists.freedesktop.org and/or
system...@lists.freedesktop.org might be where to look for answers.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[John Hasler]

Felix writes:
> IIRC this change has to do with systemd

It happens even when not using Systemd.
--
John Hasler
jha...@newsguy.com
Elmwood, WI USA

[Brian]

On Sun 22 Nov 2015 at 14:03:35 +0100, berenge...@neutralite.org wrote:

> I see.
>
> But this trick won't prevent the me to be able to see what X11 print on
> screen, right? This is the reason I do not like this behavior.

Some people have described this behaviour as a security risk. The list
archives have discussions.

> Like, for example, "/home/foo/.xinitrc: numlockx: not found", "failing to
> find font foo, falling back to bar", etc. Those messages that people not
> using big DEs can wish to access to (again, I know this is not the
> majority).
>
> Also, note that there is absolutely nothing about that in Debian release
> notes for Jessie. I tried to find something on the web about it too, but was
> never able to find anything relevant. I guess I did not used the good search
> terms.

Bug #743015.

[Brian]

On Sun 22 Nov 2015 at 08:16:50 -0600, John Hasler wrote:

> Felix writes:
> > IIRC this change has to do with systemd
>
> It happens even when not using Systemd.

Possibly something to do accomodating systemd-shim.

>From the xinit changelog;

* 10-startx-Under-Linux-start-X-on-the-current-VT.patch,
11-startx-Pass-vtX-as-long-as-the-user-did-not-specify-.patch: By default
start the server on the current VT, this is necessary to avoid logind to
see the startx session as inactive (Closes: #743015 LP: #1247484)

[The Wanderer]

In other words, it's a consequence of logind, which is part of the
systemd suite and is shipped in the systemd package.

So yes, this change does have to do with systemd - just not with the
binary named systemd, or with the init system which is (theoretically)
contained within that binary.

AFAIK I've yet to restart X since the xinit version in question hit my
system, but if I'm now going to be affected by this behavior despite not
having logind even installed on this machine, I will be - once more - at
least mildly irritated. I don't even see any indication (in 'man
startx', which is the obvious appropriate place) of how to disable this
behavior, either on the startx command line (which would be unacceptable
anyway) or in a config file...

(Digging a bit finds what is probably the appropriate command-line
option in 'man Xorg', but still no obvious indication of where to set it
in a config file, given that I have no xorg.conf and creating one seems
undesirable for other reasons.)

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Brian]

On Sun 22 Nov 2015 at 14:12:09 -0500, The Wanderer wrote:

> On 2015-11-22 at 13:26, Brian wrote:
>
> > On Sun 22 Nov 2015 at 08:16:50 -0600, John Hasler wrote:
> >
> >> Felix writes:
> >>> IIRC this change has to do with systemd
> >>
> >> It happens even when not using Systemd.
> >
> > Possibly something to do accomodating systemd-shim.
> >
> >> From the xinit changelog;
> >
> > * 10-startx-Under-Linux-start-X-on-the-current-VT.patch,
> > 11-startx-Pass-vtX-as-long-as-the-user-did-not-specify-.patch: By default
> > start the server on the current VT, this is necessary to avoid logind to
> > see the startx session as inactive (Closes: #743015 LP: #1247484)
>
> In other words, it's a consequence of logind, which is part of the
> systemd suite and is shipped in the systemd package.
>
> So yes, this change does have to do with systemd - just not with the
> binary named systemd, or with the init system which is (theoretically)
> contained within that binary.

It looks like it is. What functional disadvantage is it to a user of
sysvinit or systemd? Starting X on vt7 is not a Law of Nature.

> AFAIK I've yet to restart X since the xinit version in question hit my
> system, but if I'm now going to be affected by this behavior despite not
> having logind even installed on this machine, I will be - once more - at
> least mildly irritated. I don't even see any indication (in 'man
> startx', which is the obvious appropriate place) of how to disable this
> behavior, either on the startx command line (which would be unacceptable
> anyway) or in a config file...
>
> (Digging a bit finds what is probably the appropriate command-line
> option in 'man Xorg', but still no obvious indication of where to set it
> in a config file, given that I have no xorg.conf and creating one seems
> undesirable for other reasons.)

If the OP (or anyone else) wants X on vt7:

startx -- vt7

[David Wright]

On Sun 22 Nov 2015 at 14:03:35 (+0100), berenge...@neutralite.org wrote:
> Le 22.11.2015 10:51, Bert Riding a écrit :
> >On Sun, 22 Nov 2015 00:40:01 +0100, berenger.morel wrote:
> >>There is a behavior change I noticed when I switched to Jessie,
> >>which
> >>have always annoyed me but that I never tried to resolve.
> >>
> >>The change is that now, when I use startx on TTY1, Xorg replaces the
> >>TTY. I understand that it is not a problem for 99% of users, but I
> >>would like to know how to configure Debian to stay with the old
> >>behavior (aka: start Xorg on TTY 7+).
> >>Do someone have any clue about how to do that?
> >>Thanks.
> >>PS: I am not registed on this list, so please CC me.

It might be sensible to set your email and and that of the list in a
reply-to header. I only noticed this request because I tend to clip
excess lines from my quotations.

> >I too am not a fan of the new behavior. X now runs on the
> >terminal from
> >which it is started, so to run it on tty7 you must run a getty on
> >tty7
> >and log in there first. Do this by editing /etc/inittab (if using
> >init) or /etc/systemd/logind.conf (if using systemd.)
> >
> >Until the last month or so it was possible to use "startx --
> >tty24" to
> >run X on tty24, accessed by AltGr-F12, for instance. This also no
> >longer works. I now have tty24 listed as my ReserveVT in logind.conf
> >so that a getty is run there and I can login and then run startx.
> >
> >There are undoubtedly other ways (like screen, perhaps) to open
> >the tty
> >you prefer.
>
> I see.
> But this trick won't prevent the me to be able to see what X11 print
> on screen, right? This is the reason I do not like this behavior.
> Like, for example, "/home/foo/.xinitrc: numlockx: not found",
> "failing to find font foo, falling back to bar", etc. Those messages
> that people not using big DEs can wish to access to (again, I know
> this is not the majority).

I'm not sure I fully understand what you can't see. Is it what you
used to see on VC1 (where you ran startx from) when X was running in
VC7? When I noticed jessie's behaviour, I just altered my script for
starting X to

xxx ()
{
local TIMESTAMP=$(date +%Y-%m-%d-%H-%M-%S);
: >| $HOME/.xsession-errors;
printf '%s\n' "zzzyyyxxx $HOSTNAME $TIMESTAMP" >> $HOME/.xsession-errors;
/usr/bin/X11/startx >> $HOME/.xsession-errors 2>&1 &
}

so that everything appears in $HOME/.xsession-errors.
The only mystery to me is why, when I Ctrl-Alt-Backspace out of X,
I sometimes find the VC1 command line looks like this:

$ ŁŁŁ

(from one to three pound characters, usually zero).

Cheers,
David.

[The Wanderer]

On 2015-11-22 at 15:24, Brian wrote:

> On Sun 22 Nov 2015 at 14:12:09 -0500, The Wanderer wrote:
>
>> On 2015-11-22 at 13:26, Brian wrote:

>>> * 10-startx-Under-Linux-start-X-on-the-current-VT.patch,
>>> 11-startx-Pass-vtX-as-long-as-the-user-did-not-specify-.patch: By default
>>> start the server on the current VT, this is necessary to avoid logind to
>>> see the startx session as inactive (Closes: #743015 LP: #1247484)
>>
>> In other words, it's a consequence of logind, which is part of the
>> systemd suite and is shipped in the systemd package.
>>
>> So yes, this change does have to do with systemd - just not with
>> the binary named systemd, or with the init system which is
>> (theoretically) contained within that binary.
>
> It looks like it is. What functional disadvantage is it to a user of
> sysvinit or systemd? Starting X on vt7 is not a Law of Nature.

The loss of the ability to switch to the VT from which I started X, and
either see the most recent X console output there or (more importantly)
kill X semi-cleanly via Ctrl-C.

I have needed the latter on multiple occasions, including I think at
least one where logging in to another VT would not have been a viable
option (though I forget why, and it's possible that I'm wrong about
that). I think that's enough to count as a functional disadvantage.

Not to mention, "functional disadvantage" is not the only valid grounds
on which to object to a change... but if we try to get into that very
deeply, we'll be at risk of flamewar, of reviving the systemd flap again
(we're already skirting the edges of it), and of getting offtopic. (In
order of increasing likelihood.)

>> AFAIK I've yet to restart X since the xinit version in question hit
>> my system, but if I'm now going to be affected by this behavior
>> despite not having logind even installed on this machine, I will be
>> - once more - at least mildly irritated. I don't even see any
>> indication (in 'man startx', which is the obvious appropriate
>> place) of how to disable this behavior, either on the startx
>> command line (which would be unacceptable anyway) or in a config
>> file...
>>
>> (Digging a bit finds what is probably the appropriate command-line
>> option in 'man Xorg', but still no obvious indication of where to
>> set it in a config file, given that I have no xorg.conf and
>> creating one seems undesirable for other reasons.)
>
> If the OP (or anyone else) wants X on vt7:
>
> startx -- vt7

That requires specifying it by hand every time startx is run. As I
indicated, that is unacceptable; I don't have to specify the VT manually
every time I lanch X now in order to get the current behavior, and I
shouldn't have to specify it manually at every launch in order get that
behavior after a change of the default.

Where/how would it be possible to specify this in a config file, so that
it can be set-and-forget if desired?

(Leaving aside the fact that setting it explicitly in a config file
wouldn't replicate current behavior in the scenario where multiple
instances of X are launched on the same machine; I've had X open on vt7
and vt8 at the same time, previously, with no manual VT specifying
involved. That's something I do rarely enough that it won't affect me
personally, however; it's just something whose loss I'd find annoying in
principle.)

[Chris Bannister]

On Sun, Nov 22, 2015 at 05:56:04PM -0500, The Wanderer wrote:
> > startx -- vt7
>
> That requires specifying it by hand every time startx is run. As I
> indicated, that is unacceptable; I don't have to specify the VT manually
> every time I lanch X now in order to get the current behavior, and I
> shouldn't have to specify it manually at every launch in order get that
> behavior after a change of the default.
>
> Where/how would it be possible to specify this in a config file, so that
> it can be set-and-forget if desired?

In .bashrc (if using bash)

alias startx="startx -- vt7"

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[The Wanderer]

On 2015-11-22 at 18:52, Chris Bannister wrote:

> On Sun, Nov 22, 2015 at 05:56:04PM -0500, The Wanderer wrote:
>
>>> startx -- vt7
>>
>> That requires specifying it by hand every time startx is run. As I
>> indicated, that is unacceptable; I don't have to specify the VT
>> manually every time I lanch X now in order to get the current
>> behavior, and I shouldn't have to specify it manually at every
>> launch in order get that behavior after a change of the default.
>>
>> Where/how would it be possible to specify this in a config file, so
>> that it can be set-and-forget if desired?
>
> In .bashrc (if using bash)
>
> alias startx="startx -- vt7"

While that would technically work, it's a bit of a kludge, and I'm not
fond of those. Perhaps I should have specified an _X-related_ config
file (by a definition in which xinit, including startx, qualifies as
being X-related).

(Sorry if this looks like moving the goalposts - that's not my
intention, I'm just trying to clarify what I was originally asking for.)

[Brian]

On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:

> On 2015-11-22 at 18:52, Chris Bannister wrote:
>
> > On Sun, Nov 22, 2015 at 05:56:04PM -0500, The Wanderer wrote:
> >
> >>> startx -- vt7
> >>
> >> That requires specifying it by hand every time startx is run. As I
> >> indicated, that is unacceptable; I don't have to specify the VT
> >> manually every time I lanch X now in order to get the current
> >> behavior, and I shouldn't have to specify it manually at every
> >> launch in order get that behavior after a change of the default.
> >>
> >> Where/how would it be possible to specify this in a config file, so
> >> that it can be set-and-forget if desired?
> >
> > In .bashrc (if using bash)
> >
> > alias startx="startx -- vt7"
>
> While that would technically work, it's a bit of a kludge, and I'm not
> fond of those. Perhaps I should have specified an _X-related_ config
> file (by a definition in which xinit, including startx, qualifies as
> being X-related).

Passing arguments to startx is X-related. It's the first time I've heard
using a bash alias described as a "kludge".

> (Sorry if this looks like moving the goalposts - that's not my
> intention, I'm just trying to clarify what I was originally asking for.)

Quoting:

There are 2 reasons for this change:

1) It is needed to make Xorg run without root rights
2) The old behavior creates a new session-id (as returned by getsid()),
without registering it with PAM, this breaks session managers such
as systemd-logind.

https://patchwork.freedesktop.org/patch/23004/

[John L. Ries]

Actually, if someone is starting X via startx instead of a display
manager, it normally means either that the user is trying to test his X
configuration, or that X is only intended to run intermittently, with TTY
mode being the norm. So having X replace the terminal in that
circumstance does not at all strike me as a happy thing,

--------------------------|
John L. Ries |
Salford Systems |
Phone: (619)543-8880 x107 |
or (435)867-8885 |
--------------------------|

[John Hasler]

Then there all the new users out there who, having diligently read up on
Linux, know exactly how to open a console...

[Marc Shapiro]

My box always has three X sessions going at the same time (still on
Wheezy). I use an alias to set the vt. The value of the alias is
determined by who is logged on and running startx:

for me:
alias startx='clear; startx -- :0 vt07'

for my wife:
alias startx='clear; startx -- :1 vt08'

for my daughter:
alias startx='clear; startx -- :2 vt09'

I sincerely hope that, if and when I update to Jessie, this behavior
will still be available as this allows any one of us to sit down at the
computer and with a fixed keystroke combination get to our own X
session, while not requiring that we logon to a fixed console.

[Brian]

This behaviour is available on Jessie.

[Marc Shapiro]

Thanks!

[Vincent Lefevre]

On 2015-11-23 00:45:57 +0000, Brian wrote:
> On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
>
> > On 2015-11-22 at 18:52, Chris Bannister wrote:
> >
> > > On Sun, Nov 22, 2015 at 05:56:04PM -0500, The Wanderer wrote:
> > >
> > >>> startx -- vt7
> > >>
> > >> That requires specifying it by hand every time startx is run. As I
> > >> indicated, that is unacceptable; I don't have to specify the VT
> > >> manually every time I lanch X now in order to get the current
> > >> behavior, and I shouldn't have to specify it manually at every
> > >> launch in order get that behavior after a change of the default.
> > >>
> > >> Where/how would it be possible to specify this in a config file, so
> > >> that it can be set-and-forget if desired?
> > >
> > > In .bashrc (if using bash)
> > >
> > > alias startx="startx -- vt7"
> >
> > While that would technically work, it's a bit of a kludge, and I'm not
> > fond of those. Perhaps I should have specified an _X-related_ config
> > file (by a definition in which xinit, including startx, qualifies as
> > being X-related).
>
> Passing arguments to startx is X-related. It's the first time I've heard
> using a bash alias described as a "kludge".

Users tend to forget that they have aliases. One day, they want to
add other arguments, and things start to break because the order
of arguments matters, and they wonder why.

> Quoting:
>
> There are 2 reasons for this change:
>
> 1) It is needed to make Xorg run without root rights

Do you mean that the user now needs to be root to do "startx -- vt7"?

> 2) The old behavior creates a new session-id (as returned by getsid()),
> without registering it with PAM, this breaks session managers such
> as systemd-logind.

Couldn't registering it with PAM have been a better solution?

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Brian]

On Tue 24 Nov 2015 at 17:36:49 +0100, Vincent Lefevre wrote:

> On 2015-11-23 00:45:57 +0000, Brian wrote:
> > On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
> >
> > > On 2015-11-22 at 18:52, Chris Bannister wrote:
> > >
> > > > On Sun, Nov 22, 2015 at 05:56:04PM -0500, The Wanderer wrote:
> > > >
> > > >>> startx -- vt7
> > > >>
> > > >> That requires specifying it by hand every time startx is run. As I
> > > >> indicated, that is unacceptable; I don't have to specify the VT
> > > >> manually every time I lanch X now in order to get the current
> > > >> behavior, and I shouldn't have to specify it manually at every
> > > >> launch in order get that behavior after a change of the default.
> > > >>
> > > >> Where/how would it be possible to specify this in a config file, so
> > > >> that it can be set-and-forget if desired?
> > > >
> > > > In .bashrc (if using bash)
> > > >
> > > > alias startx="startx -- vt7"
> > >
> > > While that would technically work, it's a bit of a kludge, and I'm not
> > > fond of those. Perhaps I should have specified an _X-related_ config
> > > file (by a definition in which xinit, including startx, qualifies as
> > > being X-related).
> >
> > Passing arguments to startx is X-related. It's the first time I've heard
> > using a bash alias described as a "kludge".
>
> Users tend to forget that they have aliases. One day, they want to
> add other arguments, and things start to break because the order
> of arguments matters, and they wonder why.

That's tangential. I have a TV setup with a Debian thin client and have
been known to forget why it is connected as it is and what it does. :)

> > Quoting:
> >
> > There are 2 reasons for this change:
> >
> > 1) It is needed to make Xorg run without root rights
>
> Do you mean that the user now needs to be root to do "startx -- vt7"?

*I* don't mean anything. I was quoting what a developer said. But "no",
the user does not have to be root.

> > 2) The old behavior creates a new session-id (as returned by getsid()),
> > without registering it with PAM, this breaks session managers such
> > as systemd-logind.
>
> Couldn't registering it with PAM have been a better solution?

Above my pay grade, I'm glad to say.

[Michael Biebl]

Am 24.11.2015 um 19:01 schrieb Brian:
> On Tue 24 Nov 2015 at 17:36:49 +0100, Vincent Lefevre wrote:
>
>> On 2015-11-23 00:45:57 +0000, Brian wrote:
>>> On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
>>>
>>>> On 2015-11-22 at 18:52, Chris Bannister wrote:
>>>>

>>> There are 2 reasons for this change:
>>>
>>> 1) It is needed to make Xorg run without root rights
>>
>> Do you mean that the user now needs to be root to do "startx -- vt7"?
>
> *I* don't mean anything. I was quoting what a developer said. But "no",
> the user does not have to be root.

That's completely the wrong way around.
So far X has needed root privileges. To allow unprvileged users to run
the X servers, the binary did have the SUID bit set, which is a big
security risk.

Since enabling logind support, it's actually possible to run Xorg as
unprivileged user.

Just check your process list with ps.
In wheezy Xorg was running as root, now it runs under your userid:

$ ps aux | grep Xorg
michael 1887 1.6 0.8 378436 71028 tty2 Sl+ 03:08 18:22
/usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority
-nolisten tcp -background none -noreset -keeptty -verbose 3


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Brian]

On Tue 24 Nov 2015 at 21:13:29 +0100, Michael Biebl wrote:

> Am 24.11.2015 um 19:01 schrieb Brian:
> > On Tue 24 Nov 2015 at 17:36:49 +0100, Vincent Lefevre wrote:
> >
> >> On 2015-11-23 00:45:57 +0000, Brian wrote:
> >>> On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
> >>>
> >>>> On 2015-11-22 at 18:52, Chris Bannister wrote:
> >>>>
>
> >>> There are 2 reasons for this change:
> >>>
> >>> 1) It is needed to make Xorg run without root rights
> >>
> >> Do you mean that the user now needs to be root to do "startx -- vt7"?
> >
> > *I* don't mean anything. I was quoting what a developer said. But "no",
> > the user does not have to be root.
>
> That's completely the wrong way around.

What is the wrong way round? I've merely said root is not necessary to
use startx. Surely that is not incorrect?

> So far X has needed root privileges. To allow unprvileged users to run
> the X servers, the binary did have the SUID bit set, which is a big
> security risk.

Is SUID the exactly same as being root? (Having to be root to use startx
was what Vincent Lefevre more or less asked).

[Michael Biebl]

Am 24.11.2015 um 21:47 schrieb Brian:
> On Tue 24 Nov 2015 at 21:13:29 +0100, Michael Biebl wrote:
>
>> Am 24.11.2015 um 19:01 schrieb Brian:
>>> On Tue 24 Nov 2015 at 17:36:49 +0100, Vincent Lefevre wrote:
>>>
>>>> On 2015-11-23 00:45:57 +0000, Brian wrote:
>>>>> On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
>>>>>
>>>>>> On 2015-11-22 at 18:52, Chris Bannister wrote:
>>>>>>
>>
>>>>> There are 2 reasons for this change:
>>>>>
>>>>> 1) It is needed to make Xorg run without root rights
>>>>
>>>> Do you mean that the user now needs to be root to do "startx -- vt7"?
>>>
>>> *I* don't mean anything. I was quoting what a developer said. But "no",
>>> the user does not have to be root.
>>
>> That's completely the wrong way around.
>
> What is the wrong way round? I've merely said root is not necessary to
> use startx. Surely that is not incorrect?

This was not directed at you, just at the misconception that *now*
startx needs root. Where actually up until recently it *actually*
required root privileges (via SUID). That's what I meant with "wrong way
around".

That Xorg can now run as unprivileged user is something new (at least in
Debian), and it's a very positive change.

Sorry if that quoting was misleading.

Michael

[Brian]

On Tue 24 Nov 2015 at 22:15:25 +0100, Michael Biebl wrote:

> Am 24.11.2015 um 21:47 schrieb Brian:
> > On Tue 24 Nov 2015 at 21:13:29 +0100, Michael Biebl wrote:
> >
> >> Am 24.11.2015 um 19:01 schrieb Brian:
> >>> On Tue 24 Nov 2015 at 17:36:49 +0100, Vincent Lefevre wrote:
> >>>
> >>>> On 2015-11-23 00:45:57 +0000, Brian wrote:
> >>>>> On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
> >>>>>
> >>>>>> On 2015-11-22 at 18:52, Chris Bannister wrote:
> >>>>>>
> >>
> >>>>> There are 2 reasons for this change:
> >>>>>
> >>>>> 1) It is needed to make Xorg run without root rights
> >>>>
> >>>> Do you mean that the user now needs to be root to do "startx -- vt7"?
> >>>
> >>> *I* don't mean anything. I was quoting what a developer said. But "no",
> >>> the user does not have to be root.
> >>
> >> That's completely the wrong way around.
> >
> > What is the wrong way round? I've merely said root is not necessary to
> > use startx. Surely that is not incorrect?
>
> This was not directed at you, just at the misconception that *now*
> startx needs root. Where actually up until recently it *actually*
> required root privileges (via SUID). That's what I meant with "wrong way
> around".
>
> That Xorg can now run as unprivileged user is something new (at least in
> Debian), and it's a very positive change.

I am aware of the recent changes to Xorg (my posts should intimate that).
However, I was trying to stay away from examining the possible
consequences of starting X on a different terminal with '-- vtX' and
stick with the substance of the question.

> Sorry if that quoting was misleading.

Thank you for the clarification.

[Vincent Lefevre]

On 2015-11-25 09:32:50 +0100, Vincent Lefevre wrote:
> I agree, but there's still a contradiction with the above: what Chris
> said (quote from developers) is that X no longer uses a different TTY

I meant Brian, not Chris (quoting got wrong a few messages above).

[Vincent Lefevre]

On 2015-11-24 22:15:25 +0100, Michael Biebl wrote:
> Am 24.11.2015 um 21:47 schrieb Brian:
> > On Tue 24 Nov 2015 at 21:13:29 +0100, Michael Biebl wrote:
> >
> >> Am 24.11.2015 um 19:01 schrieb Brian:
> >>> On Tue 24 Nov 2015 at 17:36:49 +0100, Vincent Lefevre wrote:
> >>>
> >>>> On 2015-11-23 00:45:57 +0000, Brian wrote:
> >>>>> On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
> >>>>>
> >>>>>> On 2015-11-22 at 18:52, Chris Bannister wrote:
> >>>>> There are 2 reasons for this change:

^^^^^^^^^^^^^^^^^^^^^^^

> >>>>>
> >>>>> 1) It is needed to make Xorg run without root rights
> >>>>
> >>>> Do you mean that the user now needs to be root to do "startx -- vt7"?
> >>>
> >>> *I* don't mean anything. I was quoting what a developer said. But "no",
> >>> the user does not have to be root.
> >>
> >> That's completely the wrong way around.
> >
> > What is the wrong way round? I've merely said root is not necessary to
> > use startx. Surely that is not incorrect?
>
> This was not directed at you, just at the misconception that *now*
> startx needs root. Where actually up until recently it *actually*
> required root privileges (via SUID). That's what I meant with "wrong way
> around".
>
> That Xorg can now run as unprivileged user is something new (at least in
> Debian), and it's a very positive change.

I agree, but there's still a contradiction with the above: what Chris
said (quote from developers) is that X no longer uses a different TTY

so that X can run without root rights. If this is true, this means
that if the user wants to run X on a different terminal, e.g. with
"startx -- vt7", then X needs root rights, and since Xorg is no longer
SUID, this would mean that the user would have to be root to start X
in this way.

Said otherwise, if X does not need root rights with "startx -- vt7",
why is "It is needed to make Xorg run without root rights" given as
a reason for the change of behavior regarding the TTY?

[Anthony Campbell]

On 23 Nov 2015, John L. Ries wrote:
> Actually, if someone is starting X via startx instead of a display manager,
> it normally means either that the user is trying to test his X
> configuration, or that X is only intended to run intermittently, with TTY
> mode being the norm. So having X replace the terminal in that circumstance
> does not at all strike me as a happy thing,

I don't agree with this. I don't use a desktop manager but even if I
did, I'd prefer to start X via startx. This gives me more control. If
something goes wrong with X you are screwed if you don't have an easily
accessible TTY to diagnose the problem. I'm sure I'm not alone in
this.

--
Anthony Campbell http://www.acampbell.uk

[Lisi Reisz]

On Wednesday 25 November 2015 08:22:20 Anthony Campbell wrote:
> I don't agree with this. I don't use a desktop manager but even if I
> did, I'd prefer to start X via startx. This gives me more control. If
> something goes wrong with X you are screwed if you don't have an easily
> accessible TTY to diagnose the problem. I'm sure I'm not alone in
> this.

I start X via tdm. I have a very easily available/accessible TTY.

Lisi

[Brian]

Would everyone tolerate some top posting so the stall can be set up? :)

There are two issues here which I think are getting confused. The first
concerns the issue raised by the OP: using startx on vt1 gets vt1
replaced by Xorg. Background to this change in historical behaviour is
discussed in bug #747882

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747882

The result was

* 10-startx-Under-Linux-start-X-on-the-current-VT.patch,
11-startx-Pass-vtX-as-long-as-the-user-did-not-specify-.patch: By
default start the server on the current VT, this is necessary to
avoid logind to see the startx session as inactive

Suppose startx is used to bring up Xfce. With the patches a user would
not need to provide the root password to suspend the machine. If the
user starts X on another vt the session is marked as 'Active=no' and the
password for root to suspend is asked for. This has nothing to do with
whether X runs SUID or as root or not.

The second issue is about Xorg running as an unprivileged user. This
also requires X to run on the virtual console it was started from.
Presumably this is because the same intermedaries (logind and
libpam-systemd) are nvolved.

On Wed 25 Nov 2015 at 09:32:50 +0100, Vincent Lefevre wrote:

> On 2015-11-24 22:15:25 +0100, Michael Biebl wrote:
> >
> > That Xorg can now run as unprivileged user is something new (at least in
> > Debian), and it's a very positive change.
>
> I agree, but there's still a contradiction with the above: what Chris
> said (quote from developers) is that X no longer uses a different TTY
> so that X can run without root rights. If this is true, this means
> that if the user wants to run X on a different terminal, e.g. with
> "startx -- vt7", then X needs root rights, and since Xorg is no longer
> SUID, this would mean that the user would have to be root to start X
> in this way.

Untested, but I think the xserver-xorg-legacy (a setuid root Xorg server
wrapper) package would have to be installed in this circumstance.

> Said otherwise, if X does not need root rights with "startx -- vt7",
> why is "It is needed to make Xorg run without root rights" given as
> a reason for the change of behavior regarding the TTY?

This is where I think the confusion lies. Quoting

https://patchwork.freedesktop.org/patch/23004/

again.

There are 2 reasons for this change:

1) It is needed to make Xorg run without root rights

2) The old behavior creates a new session-id (as returned by getsid()),
without registering it with PAM, this breaks session managers such
as systemd-logind.

Reason 2) is the one relevant to the first post in the thread.

[Vincent Lefevre]

On 2015-11-25 12:58:15 +0000, Brian wrote:
> This is where I think the confusion lies. Quoting
>
> https://patchwork.freedesktop.org/patch/23004/
>
> again.
>
> There are 2 reasons for this change:
>
> 1) It is needed to make Xorg run without root rights
> 2) The old behavior creates a new session-id (as returned by getsid()),
> without registering it with PAM, this breaks session managers such
> as systemd-logind.
>
> Reason 2) is the one relevant to the first post in the thread.

Both are relevant. But if xserver-xorg-legacy is used as you suggested,
then I suppose that reason 2 is the one that is still relevant.

But then, if the user does "startx -- vt7", he would still be affected
by the session manager issue, possibly except with some PAM
reconfiguration.

[Brian]

On Wed 25 Nov 2015 at 15:48:48 +0100, Vincent Lefevre wrote:

> On 2015-11-25 12:58:15 +0000, Brian wrote:
> > This is where I think the confusion lies. Quoting
> >
> > https://patchwork.freedesktop.org/patch/23004/
> >
> > again.
> >
> > There are 2 reasons for this change:
> >
> > 1) It is needed to make Xorg run without root rights
> > 2) The old behavior creates a new session-id (as returned by getsid()),
> > without registering it with PAM, this breaks session managers such
> > as systemd-logind.
> >
> > Reason 2) is the one relevant to the first post in the thread.
>
> Both are relevant. But if xserver-xorg-legacy is used as you suggested,
> then I suppose that reason 2 is the one that is still relevant.

I was thinking of the OP being on Jessie. The server is SUID there.

> But then, if the user does "startx -- vt7", he would still be affected
> by the session manager issue, possibly except with some PAM
> reconfiguration.

"startx -- vt7" won't work (tested). X only runs on the virtual console
it was started from.

Play with PAM? I want a quiet life. :)

[Chris Bannister]

ctrl-alt-F1 still works, even though ctrl-alt-backspace no longer works.

[Marc Shapiro]

Not alone, at all. I run Mate, but I boot to a console, log in there,
and use startx to get my X session.

Marc

[John Hasler]

Marc writes:
> Not alone, at all. I run Mate, but I boot to a console, log in there,
> and use startx to get my X session.

So do I, and I have a decades-old muscle memory that tells me
CNTRL-ALT-F1 will get me a logged-in console. Having to reprogram that
is a (minor) nuisance. It will be a much larger nuisance for the new
users who will diligently read up on Linux before trying it (yes, there
are people who do that) and learn that CNTRL-ALT-F1 gets them to a
console and ALT-F7 gets them back to X.

[Brian]

For many readers (diligent or otherwise), isn't this a matter of updated
documentation and re-education. There are still users (an example is in
this thread) who believe ctrl-alt-backspace no longer works in Debian.
It does.

[John Hasler]

I wrote:
> So do I, and I have a decades-old muscle memory that tells me
> CNTRL-ALT-F1 will get me a logged-in console. Having to reprogram that
> is a (minor) nuisance. It will be a much larger nuisance for the new
> users who will diligently read up on Linux before trying it (yes, there
> are people who do that) and learn that CNTRL-ALT-F1 gets them to a
> console and ALT-F7 gets them back to X.

Brian writes:
> For many readers (diligent or otherwise), isn't this a matter of
> updated documentation and re-education.

There is no getting rid of the old documentation and no way to mark it
obsolete. This is a significant cost of human interface changes and
should be considered.

[Renaud OLGIATI]

On Thu, 26 Nov 2015 13:16:16 -0600
John Hasler <jha...@newsguy.com> wrote:

> > For many readers (diligent or otherwise), isn't this a matter of
> > updated documentation and re-education.

> There is no getting rid of the old documentation and no way to mark it
> obsolete. This is a significant cost of human interface changes and
> should be considered.

Only obsolete for those who have switched to systemd-Linux; the documentation remains still valid for users of GNU-Linux.

Cheers,

Ron.
--
An expert is one who knows more and more about less and less
until he knows absolutely everything about nothing.

-- http://www.olgiati-in-paraguay.org --

[Brian]

On Thu 26 Nov 2015 at 16:28:05 -0300, Renaud OLGIATI wrote:

> On Thu, 26 Nov 2015 13:16:16 -0600
> John Hasler <jha...@newsguy.com> wrote:
>
> > > For many readers (diligent or otherwise), isn't this a matter of
> > > updated documentation and re-education.
>
> > There is no getting rid of the old documentation and no way to mark it
> > obsolete. This is a significant cost of human interface changes and
> > should be considered.
>
> Only obsolete for those who have switched to systemd-Linux; the
> documentation remains still valid for users of GNU-Linux.

The Linux Sound HOWTO: Revision 1.21 2001-05-11

http://www.tldp.org/HOWTO/Sound-HOWTO/

Even non-systemd users might struggle with it when it comes to solving a
problem . :)

[John Hasler]

Renaud writes:
> Only obsolete for those who have switched to systemd-Linux; the
> documentation remains still valid for users of GNU-Linux.

True, and that only makes the problem worse. Now you have *two* sets of
confused new users.

[Renaud OLGIATI]

On Thu, 26 Nov 2015 13:46:54 -0600
John Hasler <jha...@newsguy.com> wrote:

> > Only obsolete for those who have switched to systemd-Linux; the
> > documentation remains still valid for users of GNU-Linux.

> True, and that only makes the problem worse. Now you have *two* sets of
> confused new users.

One wonders why did they abandon the principle of backward compatibility ?

Cheers,

Ron.
--
There comes a time in the affairs of a man
when he has to take the bull by the tail
and face the situation.
-- W.C. Fields

-- http://www.olgiati-in-paraguay.org --

[Brian]

On Thu 26 Nov 2015 at 17:28:05 -0300, Renaud OLGIATI wrote:

> On Thu, 26 Nov 2015 13:46:54 -0600
> John Hasler <jha...@newsguy.com> wrote:
>
> > > Only obsolete for those who have switched to systemd-Linux; the
> > > documentation remains still valid for users of GNU-Linux.
>
> > True, and that only makes the problem worse. Now you have *two* sets of
> > confused new users.
>
> One wonders why did they abandon the principle of backward compatibility ?

How does that relate to the principle of constant inovation and
improvement?

[Renaud OLGIATI]

On Thu, 26 Nov 2015 20:37:04 +0000
Brian <ad...@cityscape.co.uk> wrote:

> > One wonders why did they abandon the principle of backward compatibility ?
>
> How does that relate to the principle of constant inovation and
> improvement?

Is it that difficult to innovate and improve, without destroying what was before ?

And ensure that what worked before still works with (or in spite of) the innovations and improvements ??

[John Hasler]

Renaud writes:
> One wonders why did they abandon the principle of backward compatibility ?

Brian writes:
> How does that relate to the principle of constant inovation and
> improvement?

By way of continuity. Sometimes it is necessary to break continuity,
but it should not be done without careful thought and preparation.

[Gene Heskett]

Because this most definitely is NOT an improvement. One of the cardinal
rules in any endeavor is that you don't "fix" what has been working
flawlessly for 18 years that I know of.

There s/b a GOOD reason to change something so basic and well
established, and I have not seen that reason adequately explained yet.
Did I miss the memo?

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Chris Bannister]

So it does! Wonder why it didn't work for me on another machine. :(
(I think I also vaguely remember seeing a discussion about it ... don't
ya hate that!)

[Chris Bannister]

On Thu, Nov 26, 2015 at 08:21:55AM +1300, Chris Bannister wrote:
> On Wed, Nov 25, 2015 at 08:22:20AM +0000, Anthony Campbell wrote:
> > On 23 Nov 2015, John L. Ries wrote:
> > > Actually, if someone is starting X via startx instead of a display manager,
> > > it normally means either that the user is trying to test his X
> > > configuration, or that X is only intended to run intermittently, with TTY
> > > mode being the norm. So having X replace the terminal in that circumstance
> > > does not at all strike me as a happy thing,
> >
> > I don't agree with this. I don't use a desktop manager but even if I
> > did, I'd prefer to start X via startx. This gives me more control. If
> > something goes wrong with X you are screwed if you don't have an easily
> > accessible TTY to diagnose the problem. I'm sure I'm not alone in
> > this.
>
> ctrl-alt-F1 still works, even though ctrl-alt-backspace no longer works.

Incorrect! ctrl-alt-backspace still works, (warning: it kills X)

[Chris Bannister]

Works for me. That is alt-f7 from one of the ttys takes to me to X .

[Chris Bannister]

On Thu, Nov 26, 2015 at 03:05:26PM -0600, John Hasler wrote:
> Renaud writes:
> > One wonders why did they abandon the principle of backward compatibility ?
>
> Brian writes:
> > How does that relate to the principle of constant inovation and
> > improvement?
>
> By way of continuity. Sometimes it is necessary to break continuity,
> but it should not be done without careful thought and preparation.

Yeah, that is one of the PITA changes.
but by changing '/etc/systemd/logind.conf' to
NAutoVTs=7

then on login 'alt-F7' will change to tty7 and issue startx from there.

(untested, but it *should* work.)

[Petter Adsen]

On Fri, 27 Nov 2015 18:08:51 +1300
Chris Bannister <cbann...@slingshot.co.nz> wrote:

> On Thu, Nov 26, 2015 at 06:54:34PM +0000, Brian wrote:
> > For many readers (diligent or otherwise), isn't this a matter of
> > updated documentation and re-education. There are still users (an
> > example is in this thread) who believe ctrl-alt-backspace no longer
> > works in Debian. It does.
>
> So it does! Wonder why it didn't work for me on another machine. :(
> (I think I also vaguely remember seeing a discussion about it ...
> don't ya hate that!)

If it is not enabled, you can enable it with 'setxkbmap -option
terminate:ctrl_alt_bksp'. The man page for xorg.conf says the option
'DontZap' disallows this.

Petter

--
"I'm ionized"
"Are you sure?"
"I'm positive."

[Mauro Condarelli]

People in this thread might find interesting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801487

Regards
Mauro

[Vincent Lefevre]

On 2015-11-27 18:36:39 +1300, Chris Bannister wrote:
> but by changing '/etc/systemd/logind.conf' to
> NAutoVTs=7
>
> then on login 'alt-F7' will change to tty7 and issue startx from there.

which doesn't solve the problem at all since the goal is to type
startx from some tty and have X run on *another* tty.

[Jonathan Dowland]

On Thu, Nov 26, 2015 at 04:57:17PM -0500, Gene Heskett wrote:
> There s/b a GOOD reason to change something so basic and well
> established, and I have not seen that reason adequately explained yet.
> Did I miss the memo?

You either haven't read the whole thread or just don't agree with the
reasoning. Either way there's no missing nugget that hasn't been uncovered.

[Brian]

On Fri 27 Nov 2015 at 18:29:20 +1300, Chris Bannister wrote:

> On Wed, Nov 25, 2015 at 06:40:00PM +0000, Brian wrote:
> > On Wed 25 Nov 2015 at 15:48:48 +0100, Vincent Lefevre wrote:
> >
> > > But then, if the user does "startx -- vt7", he would still be affected
> > > by the session manager issue, possibly except with some PAM
> > > reconfiguration.
> >
> > "startx -- vt7" won't work (tested). X only runs on the virtual console
> > it was started from.
>
> Works for me. That is alt-f7 from one of the ttys takes to me to X .

I might not have been very clear. It is on the testing distribution that
"startx -- vt7" doesn't work. It gives a fatal server error.

[Brian]

On Fri 27 Nov 2015 at 10:49:09 +0100, Vincent Lefevre wrote:

> On 2015-11-27 18:36:39 +1300, Chris Bannister wrote:
> > but by changing '/etc/systemd/logind.conf' to
> > NAutoVTs=7
> >
> > then on login 'alt-F7' will change to tty7 and issue startx from there.
>
> which doesn't solve the problem at all since the goal is to type
> startx from some tty and have X run on *another* tty.

Unachievable on Jessie without considering the use of an alias.

https://lists.debian.org/debian-user/2015/11/msg00963.html

[The Wanderer]

(Phew. Sorry for the delay in replying.)

On 2015-11-22 at 19:45, Brian wrote:

> On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
>
>> On 2015-11-22 at 18:52, Chris Bannister wrote:

>>> In .bashrc (if using bash)
>>>
>>> alias startx="startx -- vt7"
>>
>> While that would technically work, it's a bit of a kludge, and I'm not
>> fond of those. Perhaps I should have specified an _X-related_ config
>> file (by a definition in which xinit, including startx, qualifies as
>> being X-related).
>
> Passing arguments to startx is X-related.

But ~/.bashrc is not X-related.

> It's the first time I've heard using a bash alias described as a
> "kludge".

It's the difference between "configuring foo to do bar" and "telling foo
to do bar every time". The latter is a workaround for either foo's lack
of the ability to do the latter, or a lack of knowledge about how to do
the former.

If it is desirable to have this to happen every time (which it plainly
is, since it has happened every time for over a decade), then it should
be possible to configure it in X, rather than having to tell X every
time to do it this way. Using a shell alias avoids the manual retyping
effort of doing it every time, but is still The Wrong Way To Do It from
a design perspective.

(Plus, using a shell alias means that either you have to use a different
command - not just 'startx' - to do the launch, or you lose the ability
to run 'startx -- foo bar baz' to pass other - or additional - options
to X at launch time. I've needed to do that for debugging purposes at
least once, and the loss of the ability to make one-off launch-time
changes that way would be aggravating.)

>> (Sorry if this looks like moving the goalposts - that's not my
>> intention, I'm just trying to clarify what I was originally asking for.)

>
> Quoting:
>
> There are 2 reasons for this change:
>
> 1) It is needed to make Xorg run without root rights

Which has never been necessary before...

I can see why it would be desirable to make it possible to run (as
opposed to launch) X under the UID of a non-root user, but IMO the
tradeoff here is not worth it - or, rather, pushing that tradeoff on
every user automatically (rather than leaving the existing behavior in
place, and enabling each user to decide for him- or herself on the
relative merits of the tradeoff) is not worth it.

(This also doesn't explain _why_ achieving that goal requires this
change... and although I can guess, the details might still be helpful.)

> 2) The old behavior creates a new session-id (as returned by getsid()),
> without registering it with PAM, this breaks session managers such
> as systemd-logind.
>

> https://patchwork.freedesktop.org/patch/23004/

That sounds like a problem for systemd-logind, which should be fixed on
that side. If you're going to introduce a change which is incompatible
with the existing ecosystem, that does not mean the existing ecosystem
should change to accommodate you, especially when doing so will break
existing behaviors for other software.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Vincent Lefevre]

On 2015-11-27 09:09:37 -0500, The Wanderer wrote:

> On 2015-11-22 at 19:45, Brian wrote:
> > Quoting:
> >
> > There are 2 reasons for this change:
> >
> > 1) It is needed to make Xorg run without root rights
>
> Which has never been necessary before...
>
> I can see why it would be desirable to make it possible to run (as
> opposed to launch) X under the UID of a non-root user, but IMO the
> tradeoff here is not worth it - or, rather, pushing that tradeoff on
> every user automatically (rather than leaving the existing behavior in
> place, and enabling each user to decide for him- or herself on the
> relative merits of the tradeoff) is not worth it.
>
> (This also doesn't explain _why_ achieving that goal requires this
> change... and although I can guess, the details might still be helpful.)

Due to /dev/tty* permissions? But IMHO, a better and more secure fix
should have been something else. Since X is a client-server system,
I don't see why it would need all the privileges of the current user
(similarly a SUID root program can drop privileges when need be).

[Brian]

On Fri 27 Nov 2015 at 09:09:37 -0500, The Wanderer wrote:

> On 2015-11-22 at 19:45, Brian wrote:
>
> > On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote:
> >
> >> On 2015-11-22 at 18:52, Chris Bannister wrote:
>
> >>> In .bashrc (if using bash)
> >>>
> >>> alias startx="startx -- vt7"
> >>
> >> While that would technically work, it's a bit of a kludge, and I'm not
> >> fond of those. Perhaps I should have specified an _X-related_ config
> >> file (by a definition in which xinit, including startx, qualifies as
> >> being X-related).
> >
> > Passing arguments to startx is X-related.
>
> But ~/.bashrc is not X-related.

Ok.

> > It's the first time I've heard using a bash alias described as a
> > "kludge".
>
> It's the difference between "configuring foo to do bar" and "telling foo
> to do bar every time". The latter is a workaround for either foo's lack
> of the ability to do the latter, or a lack of knowledge about how to do
> the former.
>
> If it is desirable to have this to happen every time (which it plainly
> is, since it has happened every time for over a decade), then it should
> be possible to configure it in X, rather than having to tell X every
> time to do it this way. Using a shell alias avoids the manual retyping
> effort of doing it every time, but is still The Wrong Way To Do It from
> a design perspective.

Could we look at this hallowed tradition of startx starting X on vt7 and
examine why it happened? 10/15 years ago most (if not all) distributions
shipped with a /etc/inittab which set up 6 ttys. I'd guess there was
nothing magical about 6. Its choice was not dictated by some underlying
principle of OS design but was plucked out of the air, maybe as some
sort of compromise. The tradition continues today with systems which use
and do not use inittab. People have got used to getting 6 ttys. All well
and good up to now.

When X is started on a tty with startx Xorg picks the first free vt it
can locate, Consequently, with an inittab it will come up on vt7, People
got used to that behaviour too. All well and good up to now.

Along came distributions which did not use inittab to establish ttys,
but you still got 6 with login prompts on them. Tradition rules. :) Log
in on tty1 and type startx. The next available tty is tty2 (there is no
login on it) so X starts there. Xorg behaves as it should and the
tradition of X on the next available vt is maintained. Again, all is
well and good.

Now (because of the requirements of logind) we depart from tradition
(sometimes hard to stomach) in Jessie and have X on the the tty it is
started from with startx.

If the patches applied to xinit were reverted we would be back to the
situation described in bug #743015

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743015

where, with or without an alias, 'start -- vt7' would be the standard
and traditional way, as it is on Jessie, to have X on vt7.

> (Plus, using a shell alias means that either you have to use a different
> command - not just 'startx' - to do the launch, or you lose the ability
> to run 'startx -- foo bar baz' to pass other - or additional - options
> to X at launch time. I've needed to do that for debugging purposes at
> least once, and the loss of the ability to make one-off launch-time
> changes that way would be aggravating.)

A fair point. I'd leave it to the user to sort this out.

> >> (Sorry if this looks like moving the goalposts - that's not my
> >> intention, I'm just trying to clarify what I was originally asking for.)
> >
> > Quoting:
> >
> > There are 2 reasons for this change:
> >
> > 1) It is needed to make Xorg run without root rights
>
> Which has never been necessary before...
>
> I can see why it would be desirable to make it possible to run (as
> opposed to launch) X under the UID of a non-root user, but IMO the
> tradeoff here is not worth it - or, rather, pushing that tradeoff on
> every user automatically (rather than leaving the existing behavior in
> place, and enabling each user to decide for him- or herself on the
> relative merits of the tradeoff) is not worth it.

Running Xorg without root rights is a separate issue from the previous
one and does not affect Jessie. On present testing/unstable a user can
choose to run Xorg with root rights or not in /etc/Xwrapper.config.

> (This also doesn't explain _why_ achieving that goal requires this
> change... and although I can guess, the details might still be helpful.)

The best I can do here is present

http://hansdegoede.livejournal.com/14268.html?page=1

> > 2) The old behavior creates a new session-id (as returned by getsid()),
> > without registering it with PAM, this breaks session managers such
> > as systemd-logind.
> >
> > https://patchwork.freedesktop.org/patch/23004/
>
> That sounds like a problem for systemd-logind, which should be fixed on
> that side. If you're going to introduce a change which is incompatible
> with the existing ecosystem, that does not mean the existing ecosystem
> should change to accommodate you, especially when doing so will break
> existing behaviors for other software.

This is not to do with Xorg and root rights.

'startx -- vt7' is at hand in Jessie with and without systemd-logind. No
ecosystems have been harmed.

[moxalt]

On Wed, 25 Nov 2015 08:22:20 +0000, Anthony Campbell <a...@acampbell.uk> wrote:

> On 23 Nov 2015, John L. Ries wrote:
> > Actually, if someone is starting X via startx instead of a display manager,
> > it normally means either that the user is trying to test his X
> > configuration, or that X is only intended to run intermittently, with TTY
> > mode being the norm. So having X replace the terminal in that circumstance
> > does not at all strike me as a happy thing,
>
> I don't agree with this. I don't use a desktop manager but even if I
> did, I'd prefer to start X via startx.

The whole point of an X display manager is that you don't need to start X
manually- you just select your session and log in. How do you envision using a
display manager and still starting X manually?

Until recently, I did not use a display manager. I used startx and Xfce. I
recently switched to MATE, and was basically told by the Debian wiki that I had
to use a display manager (so I installed LightDM too). (this is addressed to
the list now) Is this actually true? Is it possible for MATE to be configured
to work properly with permissions, PolicyKit, etc. without a DM, like Xfce is?

My MATE has all sorts of dodgy issues even with a DM when it comes to
permissions and various settings menus.

> This gives me more control. If
> something goes wrong with X you are screwed if you don't have an easily
> accessible TTY to diagnose the problem. I'm sure I'm not alone in
> this.

You're not alone in this. But technically an easily accessible TTY is still
available even with the new setup- it's just in a different VT than it used to
be. I don't really see the problem with this, since the other Alt+F<key>s
still work, and the other VTs are still accessible (although I can understand
the 'muscle memory' complaints of some').

[The Wanderer]

On 2015-11-27 at 13:14, Brian wrote:

> On Fri 27 Nov 2015 at 09:09:37 -0500, The Wanderer wrote:
>
>> On 2015-11-22 at 19:45, Brian wrote:

>>> It's the first time I've heard using a bash alias described as a
>>> "kludge".
>>
>> It's the difference between "configuring foo to do bar" and "telling foo
>> to do bar every time". The latter is a workaround for either foo's lack
>> of the ability to do the latter,

*sigh* Lack of ability to do the *former*, obviously.

>> or a lack of knowledge about how to do the former.
>>
>> If it is desirable to have this to happen every time (which it plainly
>> is, since it has happened every time for over a decade), then it should
>> be possible to configure it in X, rather than having to tell X every
>> time to do it this way. Using a shell alias avoids the manual retyping
>> effort of doing it every time, but is still The Wrong Way To Do It from
>> a design perspective.
>
> Could we look at this hallowed tradition of startx starting X on vt7 and
> examine why it happened? 10/15 years ago most (if not all) distributions
> shipped with a /etc/inittab which set up 6 ttys. I'd guess there was
> nothing magical about 6. Its choice was not dictated by some underlying
> principle of OS design but was plucked out of the air, maybe as some
> sort of compromise. The tradition continues today with systems which use
> and do not use inittab. People have got used to getting 6 ttys. All well
> and good up to now.
>
> When X is started on a tty with startx Xorg picks the first free vt it
> can locate, Consequently, with an inittab it will come up on vt7, People
> got used to that behaviour too. All well and good up to now.
>
> Along came distributions which did not use inittab to establish ttys,
> but you still got 6 with login prompts on them. Tradition rules. :) Log
> in on tty1 and type startx. The next available tty is tty2 (there is no
> login on it) so X starts there. Xorg behaves as it should and the
> tradition of X on the next available vt is maintained. Again, all is
> well and good.

Agreed. I'm not wedded strictly to having X start on vt7 in particular;
the advantage of using the traditional vt7 is that it's predictable, but
as long as I can reasonably figure out which VT it's going to be in any
given case, I don't overmuch mind if it's a different one. (It would
probably still bother me in some instances, but it's the sort of thing I
can deal with.)

I do insist on retaining all of "start on a VT different from the one
where startx was run", "dynamically pick (a / the first available) VT",
and "launch X while logged in as a (possibly specified) non-root user,
without needing the root password" - and as far as I can see, the
current changed behavior loses at least the first two of those.

> Now (because of the requirements of logind) we depart from tradition
> (sometimes hard to stomach) in Jessie and have X on the the tty it is
> started from with startx.

Which may or may not be fine for those who use logind, but should not
have to affect those - such as me - who do not. (Indeed, on my system,
logind - which is shipped in Debian within the systemd package - is not
even installed. That's on purpose; even if it were in a separate
package, I'd remove or disable it, because it has undesirable side effects.)

> If the patches applied to xinit were reverted we would be back to the
> situation described in bug #743015
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743015
>
> where, with or without an alias, 'start -- vt7' would be the standard
> and traditional way, as it is on Jessie, to have X on vt7.

I consider the behavior reported there as a bug to be the desired
behavior, and any breakage which it causes in systemd to be systemd's
problem.

Fixing that breakage in a way which causes changes for those who do not
use systemd, especially without providing (and discoverably
documenting!) a clear and straightforward way to revert those changes
without departing from the as-packaged-in-Debian software versions, is
unacceptable.


The logic in that bug report appears to be "we switched our default init
system to systemd, so we should change other things to work properly
with that".

There's nothing inherently wrong with that approach, so long as you do
not force those changes on environments which do not use that default -
but as far as I've managed to learn to date (with no personal testing
yet), at least one of those changes does seem to be so forced.

This change getting made is an example of the boogeyman of "systemd
getting its tentacles into everything". It's not a super-major one, but
every straw adds to the camel's burden, to abuse a metaphor a little.

>> (Plus, using a shell alias means that either you have to use a different
>> command - not just 'startx' - to do the launch, or you lose the ability
>> to run 'startx -- foo bar baz' to pass other - or additional - options
>> to X at launch time. I've needed to do that for debugging purposes at
>> least once, and the loss of the ability to make one-off launch-time
>> changes that way would be aggravating.)
>
> A fair point. I'd leave it to the user to sort this out.

_How_?? I don't see any practical way to avoid this problem without
compromising in some other area.

The goal here is approximately "have zero behavior change for people who
would not see the problems which led this change to be made".

As far as I can see, the only possible way to achieve that would be to
build the appropriate X-related packages locally, without the patches
which introduce this change, and keep updating them every time a new
package version is released. That's not practical or desirable.

>>> Quoting:
>>>
>>> There are 2 reasons for this change:
>>>
>>> 1) It is needed to make Xorg run without root rights
>>
>> Which has never been necessary before...
>>
>> I can see why it would be desirable to make it possible to run (as
>> opposed to launch) X under the UID of a non-root user, but IMO the
>> tradeoff here is not worth it - or, rather, pushing that tradeoff on
>> every user automatically (rather than leaving the existing behavior in
>> place, and enabling each user to decide for him- or herself on the
>> relative merits of the tradeoff) is not worth it.
>
> Running Xorg without root rights is a separate issue from the previous
> one and does not affect Jessie. On present testing/unstable a user can
> choose to run Xorg with root rights or not in /etc/Xwrapper.config.

AFAICT, only if xserver-xorg-legacy is installed - which apparently will
not be the case on a fresh Debian install, or on an ordinary
dist-upgrade. I didn't discover that package until this thread, and then
had to install it manually.

>>> 2) The old behavior creates a new session-id (as returned by getsid()),
>>> without registering it with PAM, this breaks session managers such
>>> as systemd-logind.
>>>
>>> https://patchwork.freedesktop.org/patch/23004/
>>
>> That sounds like a problem for systemd-logind, which should be fixed on
>> that side. If you're going to introduce a change which is incompatible
>> with the existing ecosystem, that does not mean the existing ecosystem
>> should change to accommodate you, especially when doing so will break
>> existing behaviors for other software.
>
> This is not to do with Xorg and root rights.
>
> 'startx -- vt7' is at hand in Jessie with and without systemd-logind. No
> ecosystems have been harmed.

I'm not sure what you're trying to say here.

The change I was referring to with the above paragraph was the
introduction, in logind, of the requirement that "X must run on the VT
from which it was launched". (For all I know, this may date back to the
first introduction of logind. Even if so, it is still a change from the
status quo prior to that point, and one which can be laid at the feet of
logind.)

The "ecosystem" includes X.org, and the Debian packaging thereof.

logind's having introduced that change does not mean X.org, or the
Debian packaging thereof, should change to accommodate that change -
especially not when doing so will change existing behaviors for people
who do not use logind.

[Chris Bannister]

Oh, really? :( Is that a bug or intended behaviour?

[Felix Miata]

The Wanderer composed on 2015-11-27 15:01 (UTC-0500):

> Brian wrote:

>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743015

>> where, with or without an alias, 'start -- vt7' would be the standard
>> and traditional way, as it is on Jessie, to have X on vt7.

On a freshly upgraded Stretch with systemd and xserver-xorg-legacy, start --
vt7 from vt3 produced a machine requiring hard reboot, before and after
'chmod 4711 /usr/bin/Xorg'.

> AFAICT, only if xserver-xorg-legacy is installed - which apparently will
> not be the case on a fresh Debian install, or on an ordinary
> dist-upgrade. I didn't discover that package until this thread, and then
> had to install it manually.

aptitude upgrade paused to warn me of the possible need
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[Vincent Lefevre]

On 2015-11-28 21:16:20 +1300, Chris Bannister wrote:
> On Fri, Nov 27, 2015 at 12:10:01PM +0000, Brian wrote:
> > On Fri 27 Nov 2015 at 18:29:20 +1300, Chris Bannister wrote:
> >
> > > On Wed, Nov 25, 2015 at 06:40:00PM +0000, Brian wrote:
> > > > "startx -- vt7" won't work (tested). X only runs on the
> > > > virtual console it was started from.
> > >
> > > Works for me. That is alt-f7 from one of the ttys takes to me to X .
> >
> > I might not have been very clear. It is on the testing distribution that
> > "startx -- vt7" doesn't work. It gives a fatal server error.
>
> Oh, really? :( Is that a bug or intended behaviour?

I don't think that this is a bug. The reason has already been given:
X needs root rights to access a different VT. But now X is no longer
SUID root...

[Nicolas George]

L'octidi 8 frimaire, an CCXXIV, Lisi Reisz a écrit :
> I can access a plethora of VTs without changing to root.

You, as far as I know, are a human being, not a Linux process. You do not
access VTs, you access computer keyboards that allow you to control VTs
through the courtesy of the getty program. The getty program run as root.

Regards,

--
Nicolas George

[Lisi Reisz]

On Saturday 28 November 2015 10:18:16 Vincent Lefevre wrote:
> X needs root rights to access a different VT

Why?

That is a real question. $USER doesn't appear to need root rights to access a
different VT.

Lisi

[Nicolas George]

L'octidi 8 frimaire, an CCXXIV, Lisi Reisz a écrit :

> $USER doesn't appear to need root rights to access a different VT.

Can you explain how you came to that conclusion?

Regards,

--
Nicolas George

[Lisi Reisz]

I can access a plethora of VTs without changing to root.

Lisi

[Lisi Reisz]

Thanks, Nocolas. But that still doesn't really explain it. If $USER can
access it, provided $USER is human, courtesy of the getty program, why can
Xorg not access it via the getty program?

And in what other ways does the system distinguish between human $USERs and
non-human $USERs? I didn't know that there were any.

Lisi

[Brian]

On Sat 28 Nov 2015 at 12:27:01 +0000, Lisi Reisz wrote:

> On Saturday 28 November 2015 10:48:00 Nicolas George wrote:
> > L'octidi 8 frimaire, an CCXXIV, Lisi Reisz a écrit :
> > > I can access a plethora of VTs without changing to root.
> >
> > You, as far as I know, are a human being, not a Linux process. You do not
> > access VTs, you access computer keyboards that allow you to control VTs
> > through the courtesy of the getty program. The getty program run as root.
>
> Thanks, Nocolas. But that still doesn't really explain it. If $USER can
> access it, provided $USER is human, courtesy of the getty program, why can
> Xorg not access it via the getty program?

As Vincent Lefevre said, root privileges are needed to access a vt other
than the one startx is used on. However, this is not sufficient because
the co-operation of logind is also needed. It will not give it,

[Lisi Reisz]

On Saturday 28 November 2015 13:06:09 Brian wrote:
> As Vincent Lefevre said, root privileges are needed to access a vt other
> than the one startx is used on.

There's a hole in my bucket, dear Eliza...

Lisi

[Chris Bannister]

On Sat, Nov 28, 2015 at 11:18:16AM +0100, Vincent Lefevre wrote:
> On 2015-11-28 21:16:20 +1300, Chris Bannister wrote:
> > On Fri, Nov 27, 2015 at 12:10:01PM +0000, Brian wrote:
> > > On Fri 27 Nov 2015 at 18:29:20 +1300, Chris Bannister wrote:
> > >
> > > > On Wed, Nov 25, 2015 at 06:40:00PM +0000, Brian wrote:
> > > > > "startx -- vt7" won't work (tested). X only runs on the
> > > > > virtual console it was started from.
> > > >
> > > > Works for me. That is alt-f7 from one of the ttys takes to me to X .
> > >
> > > I might not have been very clear. It is on the testing distribution that
> > > "startx -- vt7" doesn't work. It gives a fatal server error.
> >
> > Oh, really? :( Is that a bug or intended behaviour?
>
> I don't think that this is a bug. The reason has already been given:
> X needs root rights to access a different VT. But now X is no longer
> SUID root...

So instead of 'fatal server error.' it should be 'permission denied' in
that case?

[Brian]

On Sun 29 Nov 2015 at 04:27:59 +1300, Chris Bannister wrote:

> On Sat, Nov 28, 2015 at 11:18:16AM +0100, Vincent Lefevre wrote:
> > On 2015-11-28 21:16:20 +1300, Chris Bannister wrote:
> > > On Fri, Nov 27, 2015 at 12:10:01PM +0000, Brian wrote:
> > > > On Fri 27 Nov 2015 at 18:29:20 +1300, Chris Bannister wrote:
> > > >
> > > > > On Wed, Nov 25, 2015 at 06:40:00PM +0000, Brian wrote:
> > > > > > "startx -- vt7" won't work (tested). X only runs on the
> > > > > > virtual console it was started from.
> > > > >
> > > > > Works for me. That is alt-f7 from one of the ttys takes to me to X .
> > > >
> > > > I might not have been very clear. It is on the testing distribution that
> > > > "startx -- vt7" doesn't work. It gives a fatal server error.
> > >
> > > Oh, really? :( Is that a bug or intended behaviour?
> >
> > I don't think that this is a bug. The reason has already been given:
> > X needs root rights to access a different VT. But now X is no longer
> > SUID root...
>
> So instead of 'fatal server error.' it should be 'permission denied' in
> that case?

>From vt2:

startx -- -vt3

The screen shows

(EE)
Fatal server error:
(EE) xf86OpenConsole: Cannot open virtual console 3 (permission denied)

[Brian]

^
Obviously not.

>
> The screen shows
>
> (EE)
> Fatal server error:
> (EE) xf86OpenConsole: Cannot open virtual console 3 (permission denied)

Additionally:

xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

[Random832]

You, sitting at the keyboard, are not a process running as your login.
You are directly controlling the kernel's side of the VT driver. See how
far you get writing a shell script to write/read/open a terminal you are
not logged in on.

[John Hasler]

Lisi Reisz wrote:
> That is a real question. $USER doesn't appear to need root rights to
> access a different VT.

Input to an un-logged-in active VT is collected by a copy of getty
running as root.

man getty
--
John Hasler
jha...@newsguy.com
Elmwood, WI USA

[Neal P. Murphy]

On Mon, 30 Nov 2015 11:01:07 -0600
John Hasler <jha...@newsguy.com> wrote:

> Lisi Reisz wrote:
> > That is a real question. $USER doesn't appear to need root rights to
> > access a different VT.
>
> Input to an un-logged-in active VT is collected by a copy of getty
> running as root.

If there's a getty running on it.

'chvt 60' will switch to virtual console #60, which has no getty running. If you have read access to /dev/tty60, you can read from that tty's kbd when it is active; if you have write access, you can write to its display. If you can read /dev/vcs60, you can get a copy of the ASCII text displayed on it; if you can write, you can replace the displayed text. /dev/vcsa60 is similar, except you can also read/write at least some of the (formerly) ANSI 3.64 attributes as well as the text.

And that is at least 102k bytes of data (assuming a 25x80 screen) a miscreant could use as temporary storage that few people would think to investigate. If the video default is 75x240 (as with my video card), that climbs to 918k bytes. And on vcs7 (where X11 runs), you might have 18k bytes of scratchpad that few will find in use unless they explicitly look.

X11 runs on whichever virtual console it is told to run. Or on the current console. Or possibly on the default VC. Whichever comes first.

N

[John Hasler]

Lisi Reisz wrote:
> That is a real question. $USER doesn't appear to need root rights to
> access a different VT.

I wrote:
> Input to an un-logged-in active VT is collected by a copy of getty
> running as root.

Neal writes:
> If there's a getty running on it.

Thus "active" VT.

> If you have read access to /dev/tty60...

I don't. I'm not root.

[Martin Str|mberg]

In article <qzjse...@gated-at.bofh.it> Chris Bannister <cbann...@slingshot.co.nz> wrote:
> On Thu, Nov 26, 2015 at 06:54:34PM +0000, Brian wrote:
> > There are still users (an example is in
> > this thread) who believe ctrl-alt-backspace no longer works in Debian.
> > It does.

> So it does! Wonder why it didn't work for me on another machine. :(

It's because those nice and user-friendly DE have it disabled by
default (IIRC). I always have to go search for where they've hidden
that option this time, when I try another one or a new version.


--
MartinS

[Felix Miata]

Martin Str|mberg composed on 2015-12-02 07:39 (UTC+0100):

> Chris Bannister wrote:

>> On Thu, Nov 26, 2015 at 06:54:34PM +0000, Brian wrote:

>> > There are still users (an example is in
>> > this thread) who believe ctrl-alt-backspace no longer works in Debian.
>> > It does.

>> So it does! Wonder why it didn't work for me on another machine. :(

> It's because those nice and user-friendly DE have it disabled by
> default (IIRC). I always have to go search for where they've hidden
> that option this time, when I try another one or a new version.

I mostly use KDE, never Gnome, little other. That said,
/etc/X11/xorg.conf.d/00-keyboard.conf always works for me:

Section "InputClass"
Identifier "system-keyboard"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

[Teemu Likonen]

Felix Miata [2015-12-02 01:52:18-05] wrote:

> /etc/X11/xorg.conf.d/00-keyboard.conf always works for me:
>
> Section "InputClass"
> Identifier "system-keyboard"
> Option "XkbOptions" "terminate:ctrl_alt_bksp"
> EndSection

I think /etc/default/keyboard is a good place too:

XKBOPTIONS=terminate:ctrl_alt_bksp,plus,some,other,settings

--
/// Teemu Likonen - .-.. <https://github.com/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///