Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #160951 > unrolled thread

Xorg replaces TTY1

Back to article view | Back to linux.debian.user

Contents

  Xorg replaces TTY1 berenger.morel@neutralite.org - 2015-11-22 00:40 +0100
    Re: Xorg replaces TTY1 Bert Riding <reriding@xmission.com> - 2015-11-22 10:10 +0100
    Re: Xorg replaces TTY1 Felix Miata <mrmazda@earthlink.net> - 2015-11-22 14:50 +0100
      Re: Xorg replaces TTY1 John Hasler <jhasler@newsguy.com> - 2015-11-22 15:20 +0100
        Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-22 19:30 +0100
          Re: Xorg replaces TTY1 The Wanderer <wanderer@fastmail.fm> - 2015-11-22 20:20 +0100
            Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-22 21:30 +0100
              Re: Xorg replaces TTY1 The Wanderer <wanderer@fastmail.fm> - 2015-11-23 00:00 +0100
                Re: Xorg replaces TTY1 Chris Bannister <cbannister@slingshot.co.nz> - 2015-11-23 01:00 +0100
                  Re: Xorg replaces TTY1 The Wanderer <wanderer@fastmail.fm> - 2015-11-23 01:10 +0100
                    Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-23 01:50 +0100
                      Re: Xorg replaces TTY1 Vincent Lefevre <vincent@vinc17.net> - 2015-11-24 18:10 +0100
                        Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-24 19:10 +0100
                          Re: Xorg replaces TTY1 Michael Biebl <biebl@debian.org> - 2015-11-24 21:20 +0100
                            Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-24 21:50 +0100
                              Re: Xorg replaces TTY1 Michael Biebl <biebl@debian.org> - 2015-11-24 22:20 +0100
                                Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-24 23:40 +0100
                                Re: Xorg replaces TTY1 Vincent Lefevre <vincent@vinc17.net> - 2015-11-25 09:40 +0100
                                  Re: Xorg replaces TTY1 Vincent Lefevre <vincent@vinc17.net> - 2015-11-25 09:40 +0100
                                  Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-25 14:00 +0100
                                    Re: Xorg replaces TTY1 Vincent Lefevre <vincent@vinc17.net> - 2015-11-25 15:50 +0100
                                      Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-25 19:50 +0100
                                        Re: Xorg replaces TTY1 Chris Bannister <cbannister@slingshot.co.nz> - 2015-11-27 06:30 +0100
                                          Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-27 13:20 +0100
                                            Re: Xorg replaces TTY1 Chris Bannister <cbannister@slingshot.co.nz> - 2015-11-28 09:20 +0100
                                              Re: Xorg replaces TTY1 Vincent Lefevre <vincent@vinc17.net> - 2015-11-28 11:20 +0100
                                                Re: Xorg replaces TTY1 Nicolas George <george@nsup.org> - 2015-11-28 11:50 +0100
                                                  Re: Xorg replaces TTY1 Nicolas George <george@nsup.org> - 2015-11-28 11:50 +0100
                                                    Re: Xorg replaces TTY1 Lisi Reisz <lisi.reisz@gmail.com> - 2015-11-28 13:30 +0100
                                                      Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-28 14:10 +0100
                                                        Re: Xorg replaces TTY1 Lisi Reisz <lisi.reisz@gmail.com> - 2015-11-28 16:00 +0100
                                                  Re: Xorg replaces TTY1 Lisi Reisz <lisi.reisz@gmail.com> - 2015-11-28 11:50 +0100
                                                Re: Xorg replaces TTY1 Lisi Reisz <lisi.reisz@gmail.com> - 2015-11-28 11:50 +0100
                                                  Re: Xorg replaces TTY1 Random832 <random832@fastmail.com> - 2015-11-30 17:40 +0100
                                                    Re: Xorg replaces TTY1 John Hasler <jhasler@newsguy.com> - 2015-11-30 18:10 +0100
                                                      Re: Xorg replaces TTY1 "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu> - 2015-11-30 19:00 +0100
                                                        Re: Xorg replaces TTY1 John Hasler <jhasler@newsguy.com> - 2015-11-30 19:20 +0100
                                                Re: Xorg replaces TTY1 Chris Bannister <cbannister@slingshot.co.nz> - 2015-11-28 16:30 +0100
                                                  Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-28 18:10 +0100
                                                    Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-28 18:50 +0100
                      Re: Xorg replaces TTY1 The Wanderer <wanderer@fastmail.fm> - 2015-11-27 15:20 +0100
                        Re: Xorg replaces TTY1 Vincent Lefevre <vincent@vinc17.net> - 2015-11-27 17:50 +0100
                        Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-27 19:20 +0100
                          Re: Xorg replaces TTY1 The Wanderer <wanderer@fastmail.fm> - 2015-11-27 21:10 +0100
                            Re: Xorg replaces TTY1 Felix Miata <mrmazda@earthlink.net> - 2015-11-28 10:30 +0100
                Re: Xorg replaces TTY1 Marc Shapiro <marcnshap@gmail.com> - 2015-11-24 05:10 +0100
                  Re: Xorg replaces TTY1 Brian <ad44@cityscape.co.uk> - 2015-11-24 15:20 +0100
                    Re: Xorg replaces TTY1 Marc Shapiro <marcnshap@gmail.com> - 2015-11-24 16:20 +0100

Page 1 of 3  [1] 2 3  Next page →

#160951 — Xorg replaces TTY1

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.

[toc] | [next] | [standalone]

#160965

On Sun, 22 Nov 2015 00:40:01 +0100, berenger.morel wrote:

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

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

[toc] | [prev] | [next] | [standalone]

#160976

berenger.morel@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 xorg@lists.freedesktop.org and/or
systemd-devel@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/

[toc] | [prev] | [next] | [standalone]

#160981

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

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

[toc] | [prev] | [next] | [standalone]

#160995

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)

[toc] | [prev] | [next] | [standalone]

#160999

[Multipart message — attachments visible in raw view] — view raw

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.

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

[toc] | [prev] | [next] | [standalone]

#161001

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

[toc] | [prev] | [next] | [standalone]

#161012

[Multipart message — attachments visible in raw view] — view raw

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

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

[toc] | [prev] | [next] | [standalone]

#161027

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

[toc] | [prev] | [next] | [standalone]

#161029

[Multipart message — attachments visible in raw view] — view raw

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

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

[toc] | [prev] | [next] | [standalone]

#161035

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/

[toc] | [prev] | [next] | [standalone]

#161099

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 <vincent@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)

[toc] | [prev] | [next] | [standalone]

#161100

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.

[toc] | [prev] | [next] | [standalone]

#161102

[Multipart message — attachments visible in raw view] — view raw

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?

[toc] | [prev] | [next] | [standalone]

#161103

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

[toc] | [prev] | [next] | [standalone]

#161105

[Multipart message — attachments visible in raw view] — view raw

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

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

[toc] | [prev] | [next] | [standalone]

#161107

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.

[toc] | [prev] | [next] | [standalone]

#161124

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?

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#161125

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 Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#161130

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web