Re: [fixed]Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Max Nikulin]

On 13/09/2024 21:09, Pierre Willaime wrote:
I do not think it was related to non-free-firmware repository (Here is 
my sources.list below)


deb http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware


It seems repositories are properly configured. In general however "apt 
policy" (with no package names) is a more reliable way to inspect actual 
configuration.


In bookworm, i915 firmware is in firmware-misc-nonfree, later the 
package has been split into several parts. If everything is working fine 
then it should be installed. update-initramfs, e.g. during installing of 
kernel update, warns if some firmware files are missed. drivers may warn 
concerning firmware issues during boot as well.

[fixed]Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Pierre Willaime]

Le 11/09/2024 à 17:55, Max Nikulin a écrit :


grep -r system.conf /usr/share/dbus-1/
/usr/share/dbus-1/system.conf:  ignore_missing="yes">/etc/dbus-1/system.conf


I do not have this file as well. I suggest Pierre to compare config 
files of live and installed environments.


I recommend to read

and the similar document for bullseye. My guess is that the 
non-free-firmware repository may be missed on this machine and it may 
have impact on issues with Xorg.


I had two extra files in /etc/dbus-1

#  ls -l /etc/dbus-1/
total 8
lrwxrwxrwx 1 root root   30  3 avril  2021 session.conf -> 
/usr/share/dbus-1/session.conf
drwxr-xr-x 2 root root 4096 16 sept.  2023 session.d
lrwxrwxrwx 1 root root   29  3 avril  2021 system.conf -> 
/usr/share/dbus-1/system.conf
drwxr-xr-x 2 root root 4096  1 sept. 18:04 system.d

# grep -r system.conf /usr/share/dbus-1/
/usr/share/dbus-1/system.conf:  /etc/dbus-1/system.conf

I deleted them

# rm /etc/dbus-1/session.conf /etc/dbus-1/system.conf

And X server is starting 

Thank you all.

I guess upgrading directly from debian 9 to debian 12 prevented a script to 
remove these files.


I do not think it was related to non-free-firmware repository (Here is my 
sources.list below)

deb http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware

deb http://deb.debian.org/debian-security/ bookworm-security main contrib 
non-free non-free-firmware
deb-src http://deb.debian.org/debian-security/ bookworm-security main contrib 
non-free non-free-firmware

deb http://deb.debian.org/debian bookworm-updates main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free 
non-free-firmware

deb http://deb.debian.org/debian bookworm-backports main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian bookworm-backports main contrib non-free 
non-free-firmware

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Max Nikulin]

On 11/09/2024 22:22, Greg Wooledge wrote:

On Wed, Sep 11, 2024 at 17:16:37 +0200, Pierre Willaime wrote:

systemctl status dbus.service  shows dbus is not active ("failed") and I have 
this message

Failed to start message bus: Circular inclusion of file 
'/etc/dbus-1/system.conf'



hobbit:~$ grep -r -F system.conf /etc/dbus-1
hobbit:~$


grep -r system.conf /usr/share/dbus-1/
/usr/share/dbus-1/system.conf:  ignore_missing="yes">/etc/dbus-1/system.conf


I do not have this file as well. I suggest Pierre to compare config 
files of live and installed environments.


I recommend to read

and the similar document for bullseye. My guess is that the 
non-free-firmware repository may be missed on this machine and it may 
have impact on issues with Xorg.

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Greg Wooledge]

On Wed, Sep 11, 2024 at 17:16:37 +0200, Pierre Willaime wrote:
> systemctl status dbus.service  shows dbus is not active ("failed") and I have 
> this message
> 
> Failed to start message bus: Circular inclusion of file 
> '/etc/dbus-1/system.conf'

Curious.  I have nothing that references that file at all.

hobbit:~$ ls -l /etc/dbus-1/
total 8
drwxr-xr-x 2 root root 4096 Sep 16  2023 session.d/
drwxr-xr-x 2 root root 4096 Feb 17  2024 system.d/
hobbit:~$ grep -r -F system.conf /etc/dbus-1
hobbit:~$ 

(That's on Debian 12.)

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Pierre Willaime]

Le 09/09/2024 à 04:56, Max Nikulin a écrit :>

Have you tried to boot from a live media? It should help to
determine if your problem is caused by unsupported upgrade path.


Yes. It is booting and working fine on a debian stable live usb.


Are there any errors, warnings, or suspicious messages in "journalctl
-b" output (executed as root)?

In red in journalctl -b:

pam_systemd(login:session): Failed to connect to system bus: Connection 
refused
Failed to start dbus.service - D-Bus System Message Bus. (many times)

systemctl status dbus.service  shows dbus is not active ("failed") and I have 
this message

Failed to start message bus: Circular inclusion of file 
'/etc/dbus-1/system.conf'

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Max Nikulin]

On 09/09/2024 03:48, Pierre Willaime wrote:

Thanks. My user was *not* member of the 'input' group.

I made the change but it does not fix my issue (startx returns still an 
error, see my other email).


Have you tried to boot from a live media? It should help to determine if 
your problem is caused by unsupported upgrade path. Are there any 
errors, warnings, or suspicious messages in "journalctl -b" output 
(executed as root)?


My expectation that udev and systemd-logind "uaccess" feature should 
grant necessary permissions to the current user.

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Pierre Willaime]

On 08/09/2024 15:41, Jörg-Volker Peetz wrote:

Maybe your account is missing some authorizations.
What's the output of `id`? Is your account member of the groups 'video' 
and 'input'?


Thanks. My user was *not* member of the 'input' group.

I made the change but it does not fix my issue (startx returns still an 
error, see my other email).

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Pierre Willaime]

On 07/09/2024 23:32, Dan Ritter wrote:

Try

sudo dpkg-reconfigure xserver-xorg-legacy

and if that doesn't work, edit /etc/X11/Xwrapper.config
(and read the man page for it)


Thanks.

I tried to select "Root Only" (to restore old behavior) or "Anybody" when 
reconfiguring xserver-xorg-legacy.

There error when trying to start X is now (in either cases):

Fata server error:
(EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)

I tried also to edit directly /etc/X11/Xwrapper.config and add 
'needs_root_rights=yes|no' with no change.

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Jörg-Volker Peetz]

Maybe your account is missing some authorizations.
What's the output of `id`? Is your account member of the groups 'video' and 
'input'?
Regards,
Jörg.

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Dan Ritter]

Pierre Willaime wrote: 
> Hi,
> 
> After upgrading from Strech to Booworm (I know: not recommended to jump
> versions), I have some trouble to start X server.
> 
> startx returns this error:
> 
> "Xf86EnableIO: failed to enable I/O ports -03ff (Operation not
> permitted)".

Stretch to Buster to Bookworm would have avoided this.

In that span of time, X11 gained the ability to run without root
privileges, but only with specific support elsewhere. 

Try

sudo dpkg-reconfigure xserver-xorg-legacy

and if that doesn't work, edit /etc/X11/Xwrapper.config
(and read the man page for it)

-dsr-

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

> my workstation's hostname is the same as my login
> username, which is (obviously) also the name of my home directory.
> And yet, I've never seen this problem before.
> So, there are definitely a few more variables involved in this one.

To reproduce, run xauth list $(hostname -f):0 from a directory that
has a file or directory with the name of the workstation.  Demo:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ xauth list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth list $(hostname -f):0
Segmentation fault
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-c
57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-l
guest@redacted:~/empty$ 

The segfault has been addressed in upstream xauth-1.1.1, which is good!
Those changes are incomplete and it still gives a wrong/confusing answer
when faced with this accidental name collision.  I have a tested patch
that I'll write up and add to the 889720 report.

  - Larry

Re: startx xauth fails after upgrade to Bullseye 11.3

[David Wright]

On Thu 31 Mar 2022 at 07:30:14 (-0400), Greg Wooledge wrote:
> On Wed, Mar 30, 2022 at 10:27:25PM -0700, Larry Doolittle wrote:
> > I seem to have rediscovered Debian bug 889720
> > xauth crashes when directory name matches host name
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720
> > (Feb 2018)
> > 
> > So, nothing to do with the Bullseye upgrade.
> > I must have created that directory-matching-hostname in the
> > process of setting up for the upgrade.
> 
> Huh.  That is interesting, and confusing.  Because at work, I have the
> same setup as you -- my workstation's hostname is the same as my login
> username, which is (obviously) also the name of my home directory.
> And yet, I've never seen this problem before.
> 
> That bug report contains the clause "my .Xauthority file contains a line
> like this" which is also interesting.  Mine is not a text file.  When I
> view it in less, I'm warned that it's a binary file.  The file does not
> contain "lines" at all (looks like a mixture of text and binary data),
> and nothing that looks like "wooledg:0".  A few "wooledg", but none with
> the ":0" attached.

We can probably assume that the reporter listed it with xauth. Here's mine:

$ xauth -f .Xauthority list
HOST/unix:0  MIT-MAGIC-COOKIE-1  11223344556677889900aabbccddeeff
HOST.corp:0  MIT-MAGIC-COOKIE-1  11223344556677889900aabbccddeeff
HOST/unix:15  MIT-MAGIC-COOKIE-1  234567890abcdef1234567890abcdef1
HOST/unix:16  MIT-MAGIC-COOKIE-1  134567890abcdef1234567890abcdef2
HOST/unix:17  MIT-MAGIC-COOKIE-1  124567890abcdef1234567890abcdef3
HOST/unix:18  MIT-MAGIC-COOKIE-1  123567890abcdef1234567890abcdef4
HOST/unix:14  MIT-MAGIC-COOKIE-1  123467890abcdef1234567890abcdef5
HOST/unix:12  MIT-MAGIC-COOKIE-1  123457890abcdef1234567890abcdef6
HOST/unix:13  MIT-MAGIC-COOKIE-1  123456890abcdef1234567890abcdef7
HOST/unix:11  MIT-MAGIC-COOKIE-1  123456790abcdef1234567890abcdef8
HOST/unix:10  MIT-MAGIC-COOKIE-1  123456780abcdef1234567890abcdef9
$ ls -l .Xauthority
-rw--- 1 AUSER AUSER 548 Mar 29 10:57 .Xauthority
$ 

… where "corp" is my local domain name, and the rest is obfuscated.

I also own a file in /tmp:

$ xauth -f /tmp/serverauth.randmchars list
HOST/unix:0  MIT-MAGIC-COOKIE-1  123456789abcdef1234567890abcdef0
HOST/unix:1  MIT-MAGIC-COOKIE-1  11223344556677889900aabbccddeeff
HOST/unix:2  MIT-MAGIC-COOKIE-1  11223344556677889900aabbccddeeff
$ ls -l /tmp/serverauth.randmchars
-rw--- 1 AUSER AUSER 147 Mar 31 08:39 /tmp/serverauth.randmchars
$ 

… whose timestamp corresponds with when I booted this machine and
started X. (I can't match its first entry with anything else.)

> So, there are definitely a few more variables involved in this one.  I
> don't know why it works for some people (e.g. me) and not others.  I don't
> know the format of the ~/.Xauthority file, or why it varies across
> different Debian systems, or different login accounts.

I'm running a browser as a different local user, displayed on my X.
Their .Xauthority has an entry identical to the first entry above,
along with some different ones, and their file modification timestamp
is two hours later.

It'll be a couple of decades since I looked at what this all means.
I wrote a script that was designed to minimise retyping passwords
(pre- key authentication) when I connected and reconnected between
machines that were running Xservers.

I will say that I've never seen an entry as simple as HOST:0 …
>From the above, it might correspond to a host with no domain name.
Grasping at straws, I would check my /etc/hosts and /etc/hostname
were conformant, and that I had a domain name (like .corp).

Exim used to (does still?) complain about the lack of a domain name,
but it still performed. I don't know whether X has changed in this
regard. I wouldn't expect it to affect ordinary sockets. (I would
also have thought others would be complaining.)

Disclaimers: this particular machine is still running buster.
I don't run a DM (and I don't know what a DCOPserver is).

Cheers,
David.

Re: startx xauth fails after upgrade to Bullseye 11.3

[Greg Wooledge]

On Wed, Mar 30, 2022 at 10:27:25PM -0700, Larry Doolittle wrote:
> I seem to have rediscovered Debian bug 889720
> xauth crashes when directory name matches host name
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720
> (Feb 2018)
> 
> So, nothing to do with the Bullseye upgrade.
> I must have created that directory-matching-hostname in the
> process of setting up for the upgrade.

Huh.  That is interesting, and confusing.  Because at work, I have the
same setup as you -- my workstation's hostname is the same as my login
username, which is (obviously) also the name of my home directory.
And yet, I've never seen this problem before.

That bug report contains the clause "my .Xauthority file contains a line
like this" which is also interesting.  Mine is not a text file.  When I
view it in less, I'm warned that it's a binary file.  The file does not
contain "lines" at all (looks like a mixture of text and binary data),
and nothing that looks like "wooledg:0".  A few "wooledg", but none with
the ":0" attached.

So, there are definitely a few more variables involved in this one.  I
don't know why it works for some people (e.g. me) and not others.  I don't
know the format of the ~/.Xauthority file, or why it varies across
different Debian systems, or different login accounts.

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

I seem to have rediscovered Debian bug 889720
xauth crashes when directory name matches host name
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720
(Feb 2018)

So, nothing to do with the Bullseye upgrade.
I must have created that directory-matching-hostname in the
process of setting up for the upgrade.

  - Larry

Re: startx xauth fails after upgrade to Bullseye 11.3

[Felix Miata]

Larry Doolittle composed on 2022-03-30 19:31 (UTC-0700):

> Felix Miata wrote:

>> Is the problem avoided if you login via a display manager (gdm, sddm, 
>> lightdm,
>> etc.) instead of using startx?
 
> Beats me.  I don't have any software like that installed.

You could install one. Try LightDM. Uncompressed Size: 852 k, plus whatever 
deps.

> Would they run xauth before or after cd'ing to my home directory?

I don't know the middle of the chains of events that gets an X sessions
started, whether via DM, or startx, only some start and end points. I booted up 
a
Bullseye installation to multi-user.target, logged in, then ran startx, and got 
this:

# ls -alrtgG | tail -n9
drwxr-xr-x  3   4096 Feb  9 20:36 .mc
drwxr-xr-x 27   4096 Mar 16 21:23 ..
-rw---  1  33857 Mar 30 20:20 .bash_history
-rw---  1 99 Mar 30 20:23 .Xauthority
-rw-r--r--  1 52 Mar 30 20:23 .DCOPserver_ab560__0
lrwxrwxrwx  1 26 Mar 30 20:23 .DCOPserver_ab560_:0 -> 
/root/.DCOPserver_ab560__0
-rw---  1 31 Mar 30 20:23 .mcoprc
drwx-- 15   4096 Mar 30 20:23 .
-rw---  1 103873 Mar 30 20:23 .xsession-errors

Next I rebooted to graphical.target, logged in, and got this:
# ls -alrtgG | tail -n9
drwxr-xr-x  3   4096 Feb  9 20:36 .mc
drwxr-xr-x 27   4096 Mar 30 20:39 ..
-rw---  1 99 Mar 30 20:49 .Xauthority
-rw-r--r--  1 52 Mar 30 20:49 .DCOPserver_ab560__0
lrwxrwxrwx  1 26 Mar 30 20:49 .DCOPserver_ab560_:0 -> 
/root/.DCOPserver_ab560__0
-rw---  1 31 Mar 30 20:49 .mcoprc
-rw---  1  34072 Mar 30 20:49 .bash_history
drwx-- 15   4096 Mar 30 20:49 .
-rw---  1  48801 Mar 30 20:49 .xsession-errors
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

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

Felix Miata

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

Felix -

Felix Miata  wrote:
> Is the problem avoided if you login via a display manager (gdm, sddm, lightdm,
> etc.) instead of using startx?

Beats me.  I don't have any software like that installed.
Would they run xauth before or after cd'ing to my home directory?

  - Larry

P.S.  Sorry about breaking threading; I can only read this list
via the web.

Re: startx xauth fails after upgrade to Bullseye 11.3

[Felix Miata]

Larry Doolittle composed on 2022-03-30 08:57 (UTC-0700):

> The xauth segfault is definitely real and
> a problem for me.

Is the problem avoided if you login via a display manager (gdm, sddm, lightdm,
etc.) instead of using startx?
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

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

Felix Miata

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

Esteemed Debian experts and maintainers -

On Sun, Mar 27, 2022 at 11:26:37PM -0700, Larry Doolittle wrote:
> On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote:
> > I just upgraded my first machine from 11.2 to 11.3.
> > xauth fails in the context of startx.
> Workaround: create an empty directory, cd to that, and then startx.
> Something about running startx (and therefore xauth) in my home
> directory has it very confused.

The key command is
  xauth list $(hostname -f):0
When run in my home directory, it yields a Segmentation fault,
and leaves behind two zero-length lock files
  .Xauthority-l .Xauthority-c
that are hard-linked together.  I have to remove those files before
continuing.  When run in an empty subdirectory, that xauth command
(correctly) prints one line with an MIT-MAGIC-COOKIE-1, and
does not segfault.

In the context of /usr/bin/startx (xinit-1.4.0-1), this fault shows up
in line 199-200
authcookie=`xauth list "$displayname" \
| sed -n "s/.*$displayname[[:space:]*].*[[:space:]*]//p"` 2>/dev/null;
and the lock files left behind prevent the following xauth calls from
functioning.

I can run xauth (xauth-1:1.1-1) under gdb, but until and unless I recompile 
it with debugging symbols, the result is not so helpful:
Program received signal SIGSEGV, Segmentation fault.
__strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301
301 ../sysdeps/x86_64/multiarch/strcpy-avx2.S: No such file or directory.
(gdb) bt
#0  __strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301
#1  0x8cc3 in ?? ()
#2  0x9c8c in ?? ()
#3  0xa53d in ?? ()
#4  0xaa1e in ?? ()
#5  0x8634 in ?? ()
#6  0x77ca0d0a in __libc_start_main (main=0x8480, argc=3,
argv=0x7fffe378, init=, fini=,
rtld_fini=, stack_end=0x7fffe368)
at ../csu/libc-start.c:308
#7  0x870a in ?? ()
(gdb)

This behavior started when I upgraded to Bullseye 11.3 from 11.2.
Until I understand the fault and its trigger better, I can't guarantee 
that wasn't a coincidence.  The xauth segfault is definitely real and
a problem for me.

  - Larry

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

Esteemed Debian experts and maintainers -

On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote:
> I just upgraded my first machine from 11.2 to 11.3.
> xauth fails in the context of startx.
> Message is
>   xauth:  timeout in locking authority file /home/[redacted]/.Xauthority
> both in the startx console, and if I run "xauth list"
> in the resulting X session.

Workaround: create an empty directory, cd to that,
and then startx.  Something about running startx (and therefore xauth)
in my home directory has it very confused.  It leaves behind extra
files (hard-linked to each other): .Xauthority-c and .Xauthority-l.

  - Larry

Re: Startx works, but sddm/lightdm/xdm doesn't

[Anssi Saari]

John Goerzen  writes:

> But sddm doesn't work.  In fact, when it starts, it causes my monitor to
> go "no signal".  Oddly, though, if I can log in blindly, then once I hit
> enter after putting in my password, KDE will come up and work like it
> should.
>
> I also tried lightdm and xdm.  Both of them also had "no signal" when
> starting.

That kind of points to a problem with a shared config file. I only know
sddm a little, its startup script /etc/sddm/Xsession ends with

. /etc/X11/Xsession

so it reads commands from there. Which in turn refers a whole bunch of
config files. I'd guess xdm and lightdm do the same. But good luck
figuring out what's wrong, especially if you have a new install where
you haven't tweaked anything? You didn't restore an old home directory
from backup for example?

What about installing the non-free nvidia-driver?

> It is using the nouveau driver.  There are no errors in Xorg.0.log,
> journalctl, dmesg, syslog, or the xsession log.  lspci doesn't show any
> other graphics adapter.  xrandr on the sddm session shows it detected
> the appropriate output at the appropriate resolution.  Xorg.0.log looks
> completely appropriate; detecting devices, setting them up, etc.

Curious. I do seem to get quite a lot of messages in ~/.xsession-errors
on my laptop, although they don't all look like errors.

Re: Startx works, but sddm/lightdm/xdm doesn't

[John Goerzen]

On Mon, Feb 28 2022, Felix Miata wrote:

>> However, removing modesetting_drv.so from
>> /usr/lib/xorg/modules/drivers did.  That solved the problem.
>
>> But it didn't switch to nouveau; it went to fbdev.
>
> You likely created a new problem. modesetting_drv.so is the default DIX for 
> AMD,
> Intel and NVidia GPUs. fbdev is unaccelerated, and won't support most common
> widescreen display modes. Some apps won't run on it. I don't think Gnome will 
> even
> start using it. Using fbdev you can expect your PC to feel like it's running a
> single core at 233MHz instead of 2000MHz or more on multiple cores.

I was afraid of this, yes.

> I don't know that I've ever migrated an installation using SDDM to another PC
> using a majorly different GPU. I use TDM or KDM3 on most installations, with a
> rare few on LightDM or SDDM, whose themes I always have extreme negative
> appreciation for.

Somehow the Live CDs must be doing something that works here.  I guess
it might be interesting to see what Debian Live KDE does on this box!

John

Re: Startx works, but sddm/lightdm/xdm doesn't

[Felix Miata]

John Goerzen composed on 2022-02-28 22:11 (UTC-0600):

> Interestingly, purging xserver-xorg-video-nouveau didn't change
> anything. 

That means you must have been /using/ the modesetting DIX driver.

> However, removing modesetting_drv.so from
> /usr/lib/xorg/modules/drivers did.  That solved the problem.

> But it didn't switch to nouveau; it went to fbdev.

You likely created a new problem. modesetting_drv.so is the default DIX for AMD,
Intel and NVidia GPUs. fbdev is unaccelerated, and won't support most common
widescreen display modes. Some apps won't run on it. I don't think Gnome will 
even
start using it. Using fbdev you can expect your PC to feel like it's running a
single core at 233MHz instead of 2000MHz or more on multiple cores.

I don't know that I've ever migrated an installation using SDDM to another PC
using a majorly different GPU. I use TDM or KDM3 on most installations, with a
rare few on LightDM or SDDM, whose themes I always have extreme negative
appreciation for.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

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

Felix Miata

Re: Startx works, but sddm/lightdm/xdm doesn't

[John Goerzen]

On Mon, Feb 28 2022, Felix Miata wrote:

> There are two nouveau drivers:
>
>   kernel device
>   display device
>   modesetting
>   nouveau
>
> Both possible full-function display device drivers depend on the nouveau 
> kernel
> driver (module). inxi -Gayz will show both. Try switching from the one in 
> current
> use to the other. Adding or purging xserver-xorg-video-nouveau is typically 
> the
> simplest way to switch between them. /etc/X11/xorg.conf.d/ can also be used to
> make the switch by explicitly declaring the chosen driver. The in-use display
> driver is announced in roughly half the lines in each Xorg.#.log.

Interestingly, purging xserver-xorg-video-nouveau didn't change
anything.  However, removing modesetting_drv.so from
/usr/lib/xorg/modules/drivers did.  That solved the problem.

But it didn't switch to nouveau; it went to fbdev.

But, since I also want to boot this drive on other machines that need
it, I can't just leave it that way.  It also leaves open the question of
why it worked fine in startx, or after logging in with sddm, which is
darn weird to me.

> Try disabling Plymouth, appending one of the following to the end of the linu 
> line
> after striking the E key at the Grub menu:

Thanks for the tip; no change there (I wasn't using the graphical stuff
anyhow).

> If none help, try appending your display's native mode & refresh instead, 
> e.g.:
>
>   video=1920x1080@60
>
> If this works, likely an edit to /etc/default/grub about graphics handling or
> theme, and regeneration of /boot/grub/grub.cfg, is indicated.

It's also already getting that right from EDID, so I'm pretty sure
that's not the issue.

Thanks again!

John

Re: Startx works, but sddm/lightdm/xdm doesn't

[Nicholas Geovanis]

On Mon, Feb 28, 2022, 3:43 PM John Goerzen  wrote:

> Hi,
>
> I have a system with a GeForce 1050 Ti on bullseye.
>
> On this system, if I log in as a regular user and run startx, everything
> works fine; KDE Plasma comes up and it's all good.
>
> But sddm doesn't work.  In fact, when it starts, it causes my monitor to
> go "no signal".  Oddly, though, if I can log in blindly, then once I hit
> enter after putting in my password, KDE will come up and work like it
> should.
>
> I also tried lightdm and xdm.  Both of them also had "no signal" when
> starting.
>
> It is using the nouveau driver.  There are no errors in Xorg.0.log,
> journalctl, dmesg, syslog, or the xsession log.  lspci doesn't show any
> other graphics adapter.  xrandr on the sddm session shows it detected
> the appropriate output at the appropriate resolution.  Xorg.0.log looks
> completely appropriate; detecting devices, setting them up, etc.
>
> If I boot the same drive on a different box with Intel graphics, sddm
> works fine.
>
> This is a fresh bullseye install.
>
> A am utterly baffled; I'd think at least xdm should work!
>

I had something similar happen with Debian 8 a long time ago. It turned out
to be because the driver/firmware/grafx-chipset had the wrong idea about
the monitor's available resolutions and modes. It was using too high a
resolution.

Thanks,
>
> John
>
>

Re: Startx works, but sddm/lightdm/xdm doesn't

[Felix Miata]

John Goerzen composed on 2022-02-28 15:43 (UTC-0600):

> I have a system with a GeForce 1050 Ti on bullseye.

> On this system, if I log in as a regular user and run startx, everything
> works fine; KDE Plasma comes up and it's all good.

> But sddm doesn't work.  In fact, when it starts, it causes my monitor to
> go "no signal".  Oddly, though, if I can log in blindly, then once I hit
> enter after putting in my password, KDE will come up and work like it
> should.

> I also tried lightdm and xdm.  Both of them also had "no signal" when
> starting.

> It is using the nouveau driver. 

There are two nouveau drivers:

kernel device
display device
modesetting
nouveau

Both possible full-function display device drivers depend on the nouveau kernel
driver (module). inxi -Gayz will show both. Try switching from the one in 
current
use to the other. Adding or purging xserver-xorg-video-nouveau is typically the
simplest way to switch between them. /etc/X11/xorg.conf.d/ can also be used to
make the switch by explicitly declaring the chosen driver. The in-use display
driver is announced in roughly half the lines in each Xorg.#.log.

> There are no errors in Xorg.0.log,
> journalctl, dmesg, syslog, or the xsession log.  lspci doesn't show any
> other graphics adapter.  xrandr on the sddm session shows it detected
> the appropriate output at the appropriate resolution.  Xorg.0.log looks
> completely appropriate; detecting devices, setting them up, etc.

> If I boot the same drive on a different box with Intel graphics, sddm
> works fine.

> This is a fresh bullseye install.

> A am utterly baffled; I'd think at least xdm should work!
Try disabling Plymouth, appending one of the following to the end of the linu 
line
after striking the E key at the Grub menu:

plymouth=0
noplymouth
plymouth.enable=0

If none help, try appending your display's native mode & refresh instead, e.g.:

video=1920x1080@60

If this works, likely an edit to /etc/default/grub about graphics handling or
theme, and regeneration of /boot/grub/grub.cfg, is indicated.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

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

Felix Miata

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-25 12:08:12 +0200, Andrei POPESCU wrote:
> Alt-SysRq-F is disabled on sid:
> mar 25 12:03:28 sid kernel: SysRq : This sysrq operation is disabled.

But what if someone logs in, uses all the memory left (possibly not
even in a malicious way) so that this triggers the OOM killer, and
the OOM killer chooses the screen saver as the application to kill?

The right thing is that the screen saver should protect itself
against the OOM killer.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140325130315.ga26...@ypig.lip.ens-lyon.fr

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Andrei POPESCU]

On Vi, 21 mar 14, 10:34:03, Darac Marjal wrote:
> On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> > On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> > > 
> > > You can access the console X was started from even when the machine is
> > > locked.
> > 
> > Seriously? I'd find that to be a severe bug in the said locking 
> > application.

I have to correct myself here, apparently the application tries to do 
everything right, but...
http://www.jwz.org/xscreensaver/faq.html#no-ctl-alt-bs

> It's a feature of linux being multi-user. You come up to a machine
> that's running Xscreensaver (et al.) change to another VT, login there
> and start another X server. GDM can facilitate this with the Switch User
> functionality, but it's perfectly normal behaviour even without.
> 
> If you don't want people terminating your X session from the console, I
> think the best solution is to use a display manager, which re-uses the
> VT, and to turn on DontZap.

With a display manager one doesn't need DontZap and DontVTSwitch, as 
long as one is not logged in on one of the consoles.

Alt-SysRq-F is disabled on sid:
mar 25 12:03:28 sid kernel: SysRq : This sysrq operation is disabled.

AllowClosedownGrabs doesn't exist in xorg.conf(5) and 
Ctrl-Alt-KP_Multiply doesn't do anything on sid.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Mon 24 Mar 2014 at 12:37:36 +0100, Vincent Lefevre wrote:

> On 2014-03-23 21:06:55 +0100, Jörg-Volker Peetz wrote:
> > Seems I'm a little bit old-fashioned ;-)
> > According to the man-page Xsession(5) the system scripts take care of using 
> > a
> > log-file, given that you indeed don't have ~/.xinitrc .
> > So maybe the man-page of startx(1) has to be updated, since it only talks 
> > about
> > ~/.xinitrc .
> 
> Because startx runs the xinitrc (either the user's one or the system
> one) and doesn't know anything about the .xsession file. Xsession files
> (including the user's .xsession) are sourced via the system xinitrc.
> Perhaps a section about Debian recommendations and default configuration
> should be added.

There was a time when startx(1) contained the advice:

  Note that in the Debian system, what many people traditionally put in
  the .xinitrc file should go in .xsession instead; this permits the same
  X environment to be presented whether startx, xdm, or xinit is used to
  start the X session. All discussion of the .xinitrc file in the
  xinit(1) manual page applies equally well to .xsession. Keep in mind
  that .xinitrc is used only by xinit(1) and completely ignored by
  xdm(1).

It is interesting that there is not a single reference to .xinitrc in
Chapter 7 of the Debian Reference.

The only use I can think of off-hand for a .xinitrc is to avoid using
the Debian-specific Xsession if the system administrator has commented
out "allow-user-resources" in /etc/X11/Xsession.options.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140324124539.gl4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-23 21:06:55 +0100, Jörg-Volker Peetz wrote:
> Seems I'm a little bit old-fashioned ;-)
> According to the man-page Xsession(5) the system scripts take care of using a
> log-file, given that you indeed don't have ~/.xinitrc .
> So maybe the man-page of startx(1) has to be updated, since it only talks 
> about
> ~/.xinitrc .

Because startx runs the xinitrc (either the user's one or the system
one) and doesn't know anything about the .xsession file. Xsession files
(including the user's .xsession) are sourced via the system xinitrc.
Perhaps a section about Debian recommendations and default configuration
should be added.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140324113736.ga22...@ypig.lip.ens-lyon.fr

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jörg-Volker Peetz]

Seems I'm a little bit old-fashioned ;-)
According to the man-page Xsession(5) the system scripts take care of using a
log-file, given that you indeed don't have ~/.xinitrc .
So maybe the man-page of startx(1) has to be updated, since it only talks about
~/.xinitrc .

Best regards,
Jörg-Volker.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lgnesg$pl5$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Sat 22 Mar 2014 at 21:19:59 +0100, Sven Joachim wrote:

> On 2014-03-22 20:14 +0100, Brian wrote:
> 
> > This is the fourth or fifth time in this thread a recommendation to use
> > ~/.xinitrc has been made. No sensible Debian user would have such a file
> > in his account.
> 
> Care to elaborate why not?  If they use startx, I think they want an
> ~/.xinitrc.

>From /usr/bin/startx:

  # This is just a sample implementation of a slightly less primitive
  # interface than xinit.  It looks for user .xinitrc and .xserverrc
  # files, then system xinitrc and xserverrc files, else lets xinit choose
  # its default.  The system xinitrc should probably do things like check
  # for .Xresources files and merge them in, start up a window manager,
  # and pop a clock and several xterms.

If .xinitrc is found it is used. The system xinitrc in /etc/X11/xinit/
is not consulted. This means that none of Debian's carefully crafted
configuration files in /etc/X11 are sourced.

> > A happy Debian system is one with ~/.xsession.
> 
> I have symlinked ~/.xsession to .xinitrc, but there may be reasons for
> having different content in these files.

The consequence of a symlink is described above. With two separate files
.xsession is not used.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140323000356.gj4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Sat 22 Mar 2014 at 15:02:58 -0500, Bill Wood wrote:

> On Sat, 2014-03-22 at 19:14 +, Brian wrote:
>. . .
> > This is the fourth or fifth time in this thread a recommendation to use
> > ~/.xinitrc has been made. No sensible Debian user would have such a file
> > in his account. A happy Debian system is one with ~/.xsession.
> 
> I'm a Debian newbie, so -- why?

We had a fairly full discussion on startx, .xinitrc and .xsession in
debian-user in December of last year. The Mailing List Archives for that
month have a record of it.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014032343.gi4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Sven Joachim]

On 2014-03-22 20:14 +0100, Brian wrote:

> On Sat 22 Mar 2014 at 17:50:11 +0100, Jörg-Volker Peetz wrote:
>
>> Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
>> > In order to keep the output of the X-session when starting with the command
>> > startx, something like the following snippet could be inserted into the 
>> > file
>> > ~/.xinitrc :
>
> This is the fourth or fifth time in this thread a recommendation to use
> ~/.xinitrc has been made. No sensible Debian user would have such a file
> in his account.

Care to elaborate why not?  If they use startx, I think they want an
~/.xinitrc.

> A happy Debian system is one with ~/.xsession.

I have symlinked ~/.xsession to .xinitrc, but there may be reasons for
having different content in these files.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87siqax9xs@turtle.gmx.de

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Bill Wood]

On Sat, 2014-03-22 at 19:14 +, Brian wrote:
   . . .
> This is the fourth or fifth time in this thread a recommendation to use
> ~/.xinitrc has been made. No sensible Debian user would have such a file
> in his account. A happy Debian system is one with ~/.xsession.

I'm a Debian newbie, so -- why?

-- 
Bill Wood


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1395518578.7408.1.camel@bills-debian

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Sat 22 Mar 2014 at 17:50:11 +0100, Jörg-Volker Peetz wrote:

> Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
> > In order to keep the output of the X-session when starting with the command
> > startx, something like the following snippet could be inserted into the file
> > ~/.xinitrc :

This is the fourth or fifth time in this thread a recommendation to use
~/.xinitrc has been made. No sensible Debian user would have such a file
in his account. A happy Debian system is one with ~/.xsession.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140322191413.gh4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jörg-Volker Peetz]

Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
> In order to keep the output of the X-session when starting with the command
> startx, something like the following snippet could be inserted into the file
> ~/.xinitrc :
> 
> 
> sessid="${HOSTNAME:-$(uname -n)}-${DISPLAY##*:}"
> 
> # Send output to file
> #
> logfile="${XDG_CACHE_HOME:-$HOME}/xinit-${sessid}.log"
> : > "$logfile"
> chmod go-rwx "$logfile"
> exec > "$logfile" 2>&1
> unset logfile
> 
> 
> If the environment variable XDG_CACHE_HOME is set, the output from X is 
> written
> to, e.g., "${XDG_CACHE_HOME}/xinit-0.log" otherwise to "~/init-0.log".

Sorry, should read

to, e.g., "${XDG_CACHE_HOME}/xinit-debian-0.log" otherwise to
"~/xinit-debian-0.log" on a computer named "debian".

> 
> Regards,
> Jörg-Volker.
> 
> 
> 



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lgkevk$jbs$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jörg-Volker Peetz]

In order to keep the output of the X-session when starting with the command
startx, something like the following snippet could be inserted into the file
~/.xinitrc :


sessid="${HOSTNAME:-$(uname -n)}-${DISPLAY##*:}"

# Send output to file
#
logfile="${XDG_CACHE_HOME:-$HOME}/xinit-${sessid}.log"
: > "$logfile"
chmod go-rwx "$logfile"
exec > "$logfile" 2>&1
unset logfile


If the environment variable XDG_CACHE_HOME is set, the output from X is written
to, e.g., "${XDG_CACHE_HOME}/xinit-0.log" otherwise to "~/init-0.log".

Regards,
Jörg-Volker.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lgkbjk$gdn$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Joel Rees]

On Sat, Mar 22, 2014 at 8:51 AM, Brian  wrote:

> On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com
> wrote:
>
> > I think it depends on the situation. If you're at the library with your
> > laptop and need to go to the bathroom, it's best to take the computer
> > with you, because it's easier to just walk off with it than to dink
> > with the command prompt. I have my office in my home, where I trust
> > everyone who goes in my office, so startx is fine.
>
> This has just struck me. I wish it hadn't but Friday nights bring on
> strange thoughts:
>
> I have a picture in my mind of you and your colleagues standing in the
> bathroom and admiring each others bezels.
>

Hmm. Home office. Colleague?

Hmmm, yeah. Nothing wrong with admiring that particular colleague's
bezel, I think.

>;->

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-21 13:35:37 -0400, Steve Litt of Troubleshooters.Com wrote:
> To cure my paranoia of having stdout going to an unknown place, I made
> the following executable /usr/local/bin/exx:
> 
> ==
> #!/bin/bash
> startx > /dev/null & exit
> ==
> 
> I invoke it like this:
> 
> . exx
> 
> I think that dot space before the command is similar to "exec", which
> runs it in the current process, so the current process, rather than a
> spawned process, is what gets exited. It appears to work perfectly,
> logging out tty1 the instant X is up and running.
> 
> I didn't plan this, but this 2 line shellscript has the added benefit
> that if I forget the dot, and forgetting it would leave the bash
> session open, it tells me I don't have privileges to run X, and refuses
> to run X. So I can't make a dumb mistake.

It might be a bug and the behavior might change in the future.

To really make sure that X won't run if you forget the dot:

#!/bin/false
startx > /dev/null & exit

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140322115959.gb25...@xvii.vinc17.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-21 17:13:41 +0100, Gian Uberto Lauri wrote:
> Vincent Lefevre writes:
>  > The fact that it is multi-user doesn't mean that it will necessarily
>  > be used by several desktop users.
> 
> You can remove spawning the getty on tty you don't want to use.
> 
> I don't know how to do this with systemd... With init you had some
> nice and well commented entries in /etc/inittab
> 
> The multiple console is a feature dating back when there was no X11
> available for GNU/Linux...

Note that I do *not* want to remove the multiple console feature.
It is useful even when there is a single user.

>  > I suppose that users who use startx haven't installed a display manager.
>  > So, I think that the feature should be enabled only when a display
>  > manager is running.
>  > 
>  > Actually even better: if user A has locked his X session, then
>  > the system should prevent any switch to a Linux console where
>  > A has logged in.
> 
> This would be nice, but I think is sort of an hell... 
> 
> When the user presses the magic sequence, the one in charge of
> switching tty should pick the process table, identify X and a possible
> screen saver (how? I could use a custom written screensaver called
> ullabagulla), then identify which the parent process of X and see
> which tty it belongs to, and block any attempt to switch to that tty.

Perhaps the kernel should have a new feature that could be used
for tty switching permissions.

> AFAIK Ctrl+Alt+F1 trows a trap, therefore all the stuff above has
> to run in kernel space...

Yes, except that...

> A safer solution should be to remove all the getty except one. But
> these tty are useful to recover a system in bad times...

Even "remove all the getty except one" is not safe, because the
problem is precisely the tty where the user has logged on and run
startx.

Now, the X-locking process could still remap the keyboard to remove
all these XF86Switch_VT_* from the mappings, so that I suppose that
tty switching would no longer be possible, and restored the settings
at the end. And perhaps it can do this selectively, i.e. only do
this for tty's where the user has logged on.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140322111723.ga25...@xvii.vinc17.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:

> I think it depends on the situation. If you're at the library with your
> laptop and need to go to the bathroom, it's best to take the computer
> with you, because it's easier to just walk off with it than to dink
> with the command prompt. I have my office in my home, where I trust
> everyone who goes in my office, so startx is fine.

This has just struck me. I wish it hadn't but Friday nights bring on
strange thoughts:

I have a picture in my mind of you and your colleagues standing in the
bathroom and admiring each others bezels.

NOTE.
-

For the avoidance of any doubt and as an aid to non-native English
speakers a "bezel" can be the front surround of a monitor screen or
the panel surrounding the slot of a CD drive CD or covering empty
drive bays. It is intended to give the computer a more appealing
look.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321235148.gg4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:

> I think it depends on the situation. If you're at the library with your
> laptop and need to go to the bathroom, it's best to take the computer
> with you, because it's easier to just walk off with it than to dink
> with the command prompt. I have my office in my home, where I trust
> everyone who goes in my office, so startx is fine.

Easier? Dinking? Don't be silly.
 
> But if I were working in a cube farm with a desktop, where hundreds of
> people walk by my computer every day, and in fact some might actually
> have business being on my computer, disabling a 5 second route to a
> command prompt logged in as me would be a very good thing.

So you do not have the default tty_tickets setting as "off". Your
account; your responsibility. What's the problem?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321225815.gf4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:

> On Fri, 21 Mar 2014 11:06:03 +
> Robin  wrote:
> 
> > I may have missed something. If someone has physical access to your
> > machine can't they just power off and go into single user mode and
> > change the root password?
> 
> Unless you have a BIOS password or encrypted root partition (or
> encrypted partition where /etc resides), yes. The OP's point was that
> those things take 5 minutes, whereas killing X started by startx gives
> the guy a logged-in command prompt in about 5 seconds, especially if
> Ctrl+Alt+Backspace is enabled to instantly kill X.

I'm having difficulty seeing any inherent "insecurity" in startx (or in
sudo for that matter) and crediting the OP's two points with any
particular importance.  Firstly, a logged-in command prompt is there
without killing X and secondly you don't need to leave X to kill X.

Giving anyone free run of your account can lead to anything happening
unless you take steps to avoid it.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321175408.gd4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Steve Litt of Troubleshooters.Com]

On Fri, 21 Mar 2014 14:25:14 +0100
"Valerio Vanni"  wrote:

> "Brian"  ha scritto nel messaggio
> news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk
> 
> > For the situation when X is started with startx would 'startx &
> > exit' prevent the termination of an X session even if CTRL+ALT+FN
> > etc gets console access?
> 
> I've always used "startx & exit", and it works perfectly.
> It doesn't prevent the termination of an X session, but if it's
> terminated you get a logon prompt as if you had just booted the
> machine.

I just tried both:

startx & exit

startx; exit

The former logs out of the original bash session immediately, running X
in the background, so you see no stdout from X. I don't know where it
goes.

The latter shows the stdout from X, but when you leave X, whether
normally from Xfce or by Ctrl+C'ing in tty1, it automatically logs out
of the bash session and leaves you at the login prompt.

I guess the choice between these two depends on how valuable you think
it is to see the stdout from X (for debugging, presumably), how worried
you are about where all that stdout is going if X is run in the
background, how worried you are that somebody could find a way of
killing X and simultaneously preventing the exit to happen.

To cure my paranoia of having stdout going to an unknown place, I made
the following executable /usr/local/bin/exx:

==
#!/bin/bash
startx > /dev/null & exit
==

I invoke it like this:

. exx

I think that dot space before the command is similar to "exec", which
runs it in the current process, so the current process, rather than a
spawned process, is what gets exited. It appears to work perfectly,
logging out tty1 the instant X is up and running.

I didn't plan this, but this 2 line shellscript has the added benefit
that if I forget the dot, and forgetting it would leave the bash
session open, it tells me I don't have privileges to run X, and refuses
to run X. So I can't make a dumb mistake.

I'm probably going to start using this exx script on all my Debian
computers.

Thanks,

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321133537.5e3e923b@mydesk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

Steve Litt of Troubleshooters.Com writes:

 > I think it depends on the situation. If you're at the library with your
 > laptop and need to go to the bathroom, it's best to take the computer
 > with you, because it's easier to just walk off with it than to dink
 > with the command prompt.

Easier and  more profitable. Even  when all  the data it  contains are
available on youp...Wikimedia!

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21292.27806.549348.748...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Steve Litt of Troubleshooters.Com]

On Fri, 21 Mar 2014 11:06:03 +
Robin  wrote:

> I may have missed something. If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?

Unless you have a BIOS password or encrypted root partition (or
encrypted partition where /etc resides), yes. The OP's point was that
those things take 5 minutes, whereas killing X started by startx gives
the guy a logged-in command prompt in about 5 seconds, especially if
Ctrl+Alt+Backspace is enabled to instantly kill X.

I think it depends on the situation. If you're at the library with your
laptop and need to go to the bathroom, it's best to take the computer
with you, because it's easier to just walk off with it than to dink
with the command prompt. I have my office in my home, where I trust
everyone who goes in my office, so startx is fine.

But if I were working in a cube farm with a desktop, where hundreds of
people walk by my computer every day, and in fact some might actually
have business being on my computer, disabling a 5 second route to a
command prompt logged in as me would be a very good thing.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321123757.653c8c4e@mydesk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Steve Litt of Troubleshooters.Com]

On Fri, 21 Mar 2014 09:24:21 +
Jonathan Dowland  wrote:

> On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
> >Ctrl+Alt+F1...F12
> > For systems with virtual terminal support, these keystroke
> > combinations are used to switch to virtual terminals 1
> > through 12, respectively. This can be disabled with the
> > DontVTSwitch xorg.conf(5) file  option.
> 
> I doubt that stops e.g. chvt(1) from working. I'm sure there are a
> myriad other ways to switch VT from within the X session, too.

Not only that, but I don't think a day goes by when I don't switch to a
VT to do CLI stuff, or even to kill X because X hung (not so much in
Debian, but in other distros).

I'd rather shut down the computer when I leave to go to the bathroom
than set it up so I couldn't Ctrl+Alt+F3 to get a CLI environment any
time I wanted.

Thanks,

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321122649.69d515f7@mydesk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

Vincent Lefevre writes:
 > The fact that it is multi-user doesn't mean that it will necessarily
 > be used by several desktop users.

You can remove spawning the getty on tty you don't want to use.

I don't know how to do this with systemd... With init you had some
nice and well commented entries in /etc/inittab

The multiple console is a feature dating back when there was no X11
available for GNU/Linux...

 > I suppose that users who use startx haven't installed a display manager.
 > So, I think that the feature should be enabled only when a display
 > manager is running.
 > 
 > Actually even better: if user A has locked his X session, then
 > the system should prevent any switch to a Linux console where
 > A has logged in.

This would be nice, but I think is sort of an hell... 

When the user presses the magic sequence, the one in charge of
switching tty should pick the process table, identify X and a possible
screen saver (how? I could use a custom written screensaver called
ullabagulla), then identify which the parent process of X and see
which tty it belongs to, and block any attempt to switch to that tty.

AFAIK Ctrl+Alt+F1 trows a trap, therefore all the stuff above has
to run in kernel space...

A safer solution should be to remove all the getty except one. But
these tty are useful to recover a system in bad times...

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21292.25909.561006.437...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-21 11:41:29 +, Brian wrote:
> For the situation when X is started with startx would 'startx & exit'
> prevent the termination of an X session even if CTRL+ALT+FN etc gets
> console access?

Doing the exit immediately can have some side effects in some
configurations. For instance, my configuration requires at least
one logging shell or X being started via a display manager.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321154957.gb7...@ypig.lip.ens-lyon.fr

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-21 10:34:03 +, Darac Marjal wrote:
> On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> > On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> > > 
> > > You can access the console X was started from even when the machine is
> > > locked.
> > 
> > Seriously? I'd find that to be a severe bug in the said locking 
> > application.
> 
> It's a feature of linux being multi-user.

The fact that it is multi-user doesn't mean that it will necessarily
be used by several desktop users.

> You come up to a machine that's running Xscreensaver (et al.) change
> to another VT, login there and start another X server. GDM can
> facilitate this with the Switch User functionality, but it's
> perfectly normal behaviour even without.

I suppose that users who use startx haven't installed a display manager.
So, I think that the feature should be enabled only when a display
manager is running.

Actually even better: if user A has locked his X session, then
the system should prevent any switch to a Linux console where
A has logged in.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321153930.ga7...@ypig.lip.ens-lyon.fr

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 14:25:14 +0100, Valerio Vanni wrote:

> "Brian"  ha scritto nel messaggio
> news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk
> 
> > For the situation when X is started with startx would 'startx & exit'
> > prevent the termination of an X session even if CTRL+ALT+FN etc gets
> > console access?
> 
> I've always used "startx & exit", and it works perfectly.
> It doesn't prevent the termination of an X session, but if it's terminated 
> you get a logon prompt as if you had just booted the machine.

Indeed.

I'll return to the suggestion to use DontVTSwitch. With a locked sceen
it is effective in preventing switching to a console with CTRL+ALT+FN
and chvt even if the sudo timeout hasn't been reached.

An unlocked screen plus 'ps ax' and 'kill' enable the bringing down of X
no matter what the length of the sudo timeout is or whether DontVTSwitch
is operational.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321154029.gc4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Lisi Reisz]

On Friday 21 March 2014 11:06:03 Robin wrote:
> If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?

The default on Debian since I have been using it is that the root 
password is required for access via single user mode.  This may be 
affected by the fact that I always set a root password.

But physical access would also allow the use of a live cd. 

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201403211524.28403.lisi.re...@gmail.com

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

berenger.mo...@neutralite.org writes:
 > 
 > 
 > Le 21.03.2014 13:54, Gian Uberto Lauri a écrit :
 > > berenger.mo...@neutralite.org writes:
 > >  > Can't ~/.xinitrc force startx to logout?
 > >
 > > H, maybe if you start x with . xinitrc .

Me _idiot_! (despite the triple expresso shot).

I should have written "if you start X with «. startx» with a blank
within the . and the "startx" word.

The .xinitrc file can not do too much for a logout issue.

When  it terminates,  X dies  and this  seems to  show that  the shell
running .xinitrc is a child of X process, and the X process is a child
of the login shell. The only mean for .xinitrc to kill its grandparent
is by means of a well aimed kill -9 :).

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21292.16327.236829.55...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Valerio Vanni]

"Brian"  ha scritto nel messaggio
news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk

> For the situation when X is started with startx would 'startx & exit'
> prevent the termination of an X session even if CTRL+ALT+FN etc gets
> console access?

I've always used "startx & exit", and it works perfectly.
It doesn't prevent the termination of an X session, but if it's terminated 
you get a logon prompt as if you had just booted the machine.




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lghej2$ven$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Robin]

On 21 March 2014 11:18, Darac Marjal  wrote:
> On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
>> I may have missed something. If someone has physical access to your
>> machine can't they just power off and go into single user mode and
>> change the root password?
>
> Maybe, maybe not. Console access doesn't have to mean complete access.
> The scenario I always have in my head for these sorts of things is a
> Computer Lab at a university/college. You can allow anyone to come up
> and use the machine via the keyboard/mouse/VDU attached to it, but to
> counter the attack vector you mention, you simply lock the computer
> itself away in a secure cage under the desk. That also stops the
> "security vector" of someone simply picking up the machine and walking
> off with it ;)
>

Sorry my mail was a bit terse. I was referring to whether a DM is more
secure than startx when there is physical access to a machine.

-- 
rob


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caozwb-pam8gh4dtbf-pgvfu+sueuqjfaxwp_tjyasnvzlkj...@mail.gmail.com

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[berenger . morel]

Le 21.03.2014 13:54, Gian Uberto Lauri a écrit :

berenger.mo...@neutralite.org writes:
 > Can't ~/.xinitrc force startx to logout?

H, maybe if you start x with . xinitrc . Would you forgive me if 
I

don't do the test right now and continue to do the work I am paid for
:) ?


Currently, you do not, except if you are paid to do some support on 
debian ml. If so, I'm really jealous :D


Except that point, no problem for me, if you do not try now.
I did a very quick test, but it did not worked. Now, I'm not sure that 
I've modified the good file: when doing startx with root ( just to try, 
I do not usually do this ) my window manager is started correctly, and 
there is no .xinitrc there. But if you want to play with this 
possibility, feel free to do so, I'm really interested.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/89eee6b2e416d81d7b29dad50e67b...@neutralite.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

berenger.mo...@neutralite.org writes:
 > Can't ~/.xinitrc force startx to logout?

H, maybe if you start x with . xinitrc . Would you forgive me if I
don't do the test right now and continue to do the work I am paid for
:) ?

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21292.13933.899681.244...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[berenger . morel]

Le 20.03.2014 02:44, Zenaan Harkness a écrit :
Yeah, when making a machine for a less technical or less 
command-prompt

comfortable person, I like to have it boot into GUI via the desktop
manager. But when setting it up for myself or for people technically
sharp enough to log in and then type "startx" (and people you can
trust with the command prompt), I like to boot to the command 
prompt.


When logging in at the Linux console (on current kernels at least),
then running startx, there is a security problem:

Anyone with physical access to your computer could:

a) logout of your gui session (if it's not screensaver locked), 
taking

them back to your command line, and depending on your settings of
/etc/sudoers tty_tickets or respectively !tty_tickets setting - see
man sudoers) might give them instant root access;
either way, mischief may ensure.

b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your 
gui

session, notwithstanding if you even have it gui locked


SO: what to do?

What I did for a while was:
a) log in to Linux console
b) startx; exit

This way, when the gui (X in this case) exits for any reason, then 
the

console shell session logs out automatically.

That's fine, but requires more typing, and remembering to add the
extra "; exit" command.

So to optimize, simply put the sequency "startx; exit" (or similar)
into a shell function - I use the name "se" since it's less to type 
:)


So now I use:
a) log in to Linux console
b) se

Happy and safe sessions to all,
Zenaan


Can't ~/.xinitrc force startx to logout?
And about TTYs, I guess that, for most users, the easiest thing to do 
is to disable all but one for the usual runlevel. ( /etc/inittab could 
help )



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/810fee07a22880f1c573348502743...@neutralite.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 11:18:19 +, Darac Marjal wrote:

> On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
> > I may have missed something. If someone has physical access to your
> > machine can't they just power off and go into single user mode and
> > change the root password?
> 
> Maybe, maybe not. Console access doesn't have to mean complete access.
> The scenario I always have in my head for these sorts of things is a
> Computer Lab at a university/college. You can allow anyone to come up
> and use the machine via the keyboard/mouse/VDU attached to it, but to
> counter the attack vector you mention, you simply lock the computer
> itself away in a secure cage under the desk. That also stops the
> "security vector" of someone simply picking up the machine and walking
> off with it ;)

For the situation when X is started with startx would 'startx & exit'
prevent the termination of an X session even if CTRL+ALT+FN etc gets
console access?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21032014113647.c62190855...@desktop.copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Darac Marjal]

On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
> I may have missed something. If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?

Maybe, maybe not. Console access doesn't have to mean complete access.
The scenario I always have in my head for these sorts of things is a
Computer Lab at a university/college. You can allow anyone to come up
and use the machine via the keyboard/mouse/VDU attached to it, but to
counter the attack vector you mention, you simply lock the computer
itself away in a secure cage under the desk. That also stops the
"security vector" of someone simply picking up the machine and walking
off with it ;)



signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Robin]

I may have missed something. If someone has physical access to your
machine can't they just power off and go into single user mode and
change the root password?

-- 
rob


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caozwb-q+wwdadb6nz0rrhprqvmzc0_y3oi36v55a2h7yrfo...@mail.gmail.com

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 10:24:54 +, Jonathan Dowland wrote:

> On Fri, Mar 21, 2014 at 09:52:03AM +, Brian wrote:
> > In an xterm (with or without using DontVTSwitch):
> > 
> >brian@localhost:~$ chvt 4
> >Couldn't gat a file descriptor referring to the console
> > 
> > Doubt no longer. :)
> 
> Try via sudo. (risk reduced to: X session left open, terminal left open,
> non-expired sudo ticket in that terminal)

Didn't think of that. You're correct, of course. Thanks for the
explanation.

> I'm still sure there will be many other ways to do it, although they may
> require privileges to do so.

I'm convinced.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21032014103947.7b37bc831...@desktop.copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Darac Marjal]

On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> > 
> > You can access the console X was started from even when the machine is
> > locked.
> 
> Seriously? I'd find that to be a severe bug in the said locking 
> application.

It's a feature of linux being multi-user. You come up to a machine
that's running Xscreensaver (et al.) change to another VT, login there
and start another X server. GDM can facilitate this with the Switch User
functionality, but it's perfectly normal behaviour even without.

If you don't want people terminating your X session from the console, I
think the best solution is to use a display manager, which re-uses the
VT, and to turn on DontZap.



signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jonathan Dowland]

On Fri, Mar 21, 2014 at 09:52:03AM +, Brian wrote:
> In an xterm (with or without using DontVTSwitch):
> 
>brian@localhost:~$ chvt 4
>Couldn't gat a file descriptor referring to the console
> 
> Doubt no longer. :)

Try via sudo. (risk reduced to: X session left open, terminal left open,
non-expired sudo ticket in that terminal)

I'm still sure there will be many other ways to do it, although they may
require privileges to do so.

Having said all the above, I'd advocate using a display manager for the
vast majority of people.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321102454.ga16...@bryant.redmars.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 09:24:21 +, Jonathan Dowland wrote:

> On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
> >Ctrl+Alt+F1...F12
> > For systems with virtual terminal support, these keystroke
> > combinations are used to switch to virtual terminals 1
> > through 12, respectively. This can be disabled with the
> > DontVTSwitch xorg.conf(5) file  option.
> 
> I doubt that stops e.g. chvt(1) from working. I'm sure there are a
> myriad other ways to switch VT from within the X session, too.

In an xterm (with or without using DontVTSwitch):

   brian@localhost:~$ chvt 4
   Couldn't gat a file descriptor referring to the console

Doubt no longer. :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321095203.gb4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Andrei POPESCU]

On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> 
> You can access the console X was started from even when the machine is
> locked.

Seriously? I'd find that to be a severe bug in the said locking 
application.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jonathan Dowland]

On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
>Ctrl+Alt+F1...F12
> For systems with virtual terminal support, these keystroke
> combinations are used to switch to virtual terminals 1
> through 12, respectively. This can be disabled with the
> DontVTSwitch xorg.conf(5) file  option.

I doubt that stops e.g. chvt(1) from working. I'm sure there are a
myriad other ways to switch VT from within the X session, too.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321092421.ga15...@bryant.redmars.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

Andrei POPESCU writes:

 > 3. any user, with or without root access, who doesn't lock his 
 > workstation as needed[1] deserves his fate.

And does not uses startx; exit

You can access the console X was started from even when the machine is
locked.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21291.64953.782916.83...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Andrei POPESCU]

On Jo, 20 mar 14, 12:44:21, Zenaan Harkness wrote:
> 
> Anyone with physical access to your computer could:
> 
> a) logout of your gui session (if it's not screensaver locked), taking
> them back to your command line, and depending on your settings of
> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
> man sudoers) might give them instant root access;
> either way, mischief may ensure.

1. tty_tickets is enabled by default

2. even if you do disable it, if my understanding of the man page is 
correct, the attacker doesn't need the console, but can use any terminal 
emulator (as another poster already mentioned)

3. any user, with or without root access, who doesn't lock his 
workstation as needed[1] deserves his fate.

[1] IMVHO it's reasonable to have different policies at home compared to 
publicly installed (work) computers, but always locking your workstation 
is probably a good habit to acquire.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Wed 19 Mar 2014 at 22:48:49 -0400, Steve Litt of Troubleshooters.Com wrote:

> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness  wrote:
> 
> > SO: what to do?
> > 
> > What I did for a while was:
> > a) log in to Linux console
> > b) startx; exit
> 
> Outstanding! I'm going to start doing that. Thanks.

This looks like a solution in search of a problem. Instant root access
would be available within X if tty_tickets is set off.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140320162709.gq26...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Thu 20 Mar 2014 at 12:44:21 +1100, Zenaan Harkness wrote:

> > Yeah, when making a machine for a less technical or less command-prompt
> > comfortable person, I like to have it boot into GUI via the desktop
> > manager. But when setting it up for myself or for people technically
> > sharp enough to log in and then type "startx" (and people you can
> > trust with the command prompt), I like to boot to the command prompt.
> 
> When logging in at the Linux console (on current kernels at least),
> then running startx, there is a security problem:
> 
> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
> session, notwithstanding if you even have it gui locked

Use the Force, Zenaan:

   man xorg

and then

   Ctrl+Alt+F1...F12
For systems with virtual terminal support, these keystroke
combinations are used to switch to virtual terminals 1
through 12, respectively. This can be disabled with the
DontVTSwitch xorg.conf(5) file  option.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20032014141516.099233063...@desktop.copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Curt]

On 2014-03-20, Vincent Lefevre  wrote:
>
> For instance, type:
>
>   sleep 2; exit
>
> and Ctrl-C just after. The "sleep 2" is interrupted, but "exit"
> isn't run.
>
> You could still do "exec startx", but this may not be OK if you
> want *logout files to be sourced for clean-up.

Not using sudo would maybe be the most robust solution.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnlilg5d.233.cu...@einstein.electron.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-20 12:44:21 +1100, Zenaan Harkness wrote:
> When logging in at the Linux console (on current kernels at least),
> then running startx, there is a security problem:
> 
> Anyone with physical access to your computer could:
> 
> a) logout of your gui session (if it's not screensaver locked), taking
> them back to your command line, and depending on your settings of
> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
> man sudoers) might give them instant root access;
> either way, mischief may ensure.
> 
> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
> session, notwithstanding if you even have it gui locked
> 
> 
> SO: what to do?
> 
> What I did for a while was:
> a) log in to Linux console
> b) startx; exit

Does it really solve the problem?

For instance, type:

  sleep 2; exit

and Ctrl-C just after. The "sleep 2" is interrupted, but "exit"
isn't run.

You could still do "exec startx", but this may not be OK if you
want *logout files to be sourced for clean-up.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140320085249.ga31...@xvii.vinc17.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Scott Ferguson]

On 20/03/14 13:48, Steve Litt of Troubleshooters.Com wrote:
> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness  wrote:
> 
>>> Yeah, when making a machine for a less technical or less
>>> command-prompt comfortable person, I like to have it boot into GUI
>>> via the desktop manager. But when setting it up for myself or for
>>> people technically sharp enough to log in and then type
>>> "startx" (and people you can trust with the command prompt), I like
>>> to boot to the command prompt.
>>
>> When logging in at the Linux console (on current kernels at least),
>> then running startx, there is a security problem:
>>

> 
> Of course, if a badguy has physical access, then you're pretty much
> screwed anyway: 

Yes. And no.
Contrary to "popular" "belief" - if someone has physical access it's
*not* "game over".
The plural of anecdote is not fact, possible != probable, and probable
!= certain. :)

If someone breaks into your house they could break into your safe. It's
not reason to not have a safe.



Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/532a82d8.6090...@gmail.com

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Zenaan Harkness]

On 3/20/14, Zenaan Harkness  wrote:
> On 3/20/14, Steve Litt of Troubleshooters.Com  wrote:
>> On Thu, 20 Mar 2014 12:44:21 +1100
>> Zenaan Harkness  wrote:
>>
>>> > Yeah, when making a machine for a less technical or less
>>> > command-prompt comfortable person, I like to have it boot into GUI
>>> > via the desktop manager. But when setting it up for myself or for
>>> > people technically sharp enough to log in and then type
>>> > "startx" (and people you can trust with the command prompt), I like
>>> > to boot to the command prompt.
>>>
>>> When logging in at the Linux console (on current kernels at least),
>>> then running startx, there is a security problem:
>>>
>>> Anyone with physical access to your computer could:
>>>
>>> a) logout of your gui session (if it's not screensaver locked), taking
>>> them back to your command line, and depending on your settings of
>>> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
>>> man sudoers) might give them instant root access;
>>> either way, mischief may ensure.
>>>
>>> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
>>> session, notwithstanding if you even have it gui locked
>>>
>>>
>>> SO: what to do?
>>>
>>> What I did for a while was:
>>> a) log in to Linux console
>>> b) startx; exit
>>>
>>> This way, when the gui (X in this case) exits for any reason, then the
>>> console shell session logs out automatically.
>>>
>>> That's fine, but requires more typing, and remembering to add the
>>> extra "; exit" command.
>>>
>>> So to optimize, simply put the sequency "startx; exit" (or similar)
>>> into a shell function - I use the name "se" since it's less to type :)
>>>
>>> So now I use:
>>> a) log in to Linux console
>>> b) se
>>>
>>> Happy and safe sessions to all,
>>> Zenaan
>>
>> Outstanding! I'm going to start doing that. Thanks.
>
> You're welcome.
>
>> What shellscript contains the se function on your system?
>
> My system is not relevant. The point is, it needs to be in one of your
> startup scripts. If you use the GNU Bash shell, then you might try
> ~/.bashrc
>
> Other shells might have different function declaration syntax, and
> different put-this-function-in-my-environment syntax.
>
> I have attached my ~/lib/libintrospect.sh file and added the se
> function to the bottom, so you can see how this works for bash,
> including a function which can be used to export all declared
> functions - you may of course only want to export one or two
> functions, but at least this shows you how to do that.
>
> I plan to tidy up my bash libraries and upload them - hopefully this year.
>
>
>> Of course, if a badguy has physical access, then you're pretty much
>> screwed anyway: If you don't have a bios password they can boot System
>> Rescue CD, mount your root partition, delete the x in the second field
>> of root's record (or your record if there's no root), log in, press
>> enter, log in, change the password to something they like, and have
>> their way with the machine.
>
> Of course. This is simply one extra layer of protection, and will only
> protect you against a quick-and-dirty type attach which might
> otherwise be done in just a few seconds. This script can prevent that
> type of physical-access attack, so it's much better than nothing.
>
> Enjoy,
> Zenaan

I'm not sure it came through, I just got this error:
Subject: [MailServer Notification]Attachment Blocking Notification
From: Administrator 
Date: Thu, Mar 20, 2014 at 2:56 PM
To: z...@freedbms.net

The libintrospect.sh has been blocked,
and Quarantine entire message has been taken on 3/20/2014 5:55:46 AM.

Message details:
Server: HEMATIT
Sender: z...@freedbms.net;
Recipient: debian-user@lists.debian.org;
Subject: Re: Security Implications of running startx from command line -
was Re: Startx: was Great Debian experience
Attachment name: libintrospect.sh

If so, then here's the libintrospect.sh file for cutting and pasting:
[ -n "$ZLIB_INTROSPECT" ] && return || typeset -xr ZLIB_INTROSPECT=0

# Copyright 2014, Zenaan Harkness, g...@freedbms.net

# License: This file may be distributed under the terms of the GNU General
# Public License, either version 3, or at your option, any later version.

# WARNING: Distributed with no warranty of any sort, implied or otherwise.

##
# library: libi

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Zenaan Harkness]

On 3/20/14, Steve Litt of Troubleshooters.Com  wrote:
> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness  wrote:
>
>> > Yeah, when making a machine for a less technical or less
>> > command-prompt comfortable person, I like to have it boot into GUI
>> > via the desktop manager. But when setting it up for myself or for
>> > people technically sharp enough to log in and then type
>> > "startx" (and people you can trust with the command prompt), I like
>> > to boot to the command prompt.
>>
>> When logging in at the Linux console (on current kernels at least),
>> then running startx, there is a security problem:
>>
>> Anyone with physical access to your computer could:
>>
>> a) logout of your gui session (if it's not screensaver locked), taking
>> them back to your command line, and depending on your settings of
>> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
>> man sudoers) might give them instant root access;
>> either way, mischief may ensure.
>>
>> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
>> session, notwithstanding if you even have it gui locked
>>
>>
>> SO: what to do?
>>
>> What I did for a while was:
>> a) log in to Linux console
>> b) startx; exit
>>
>> This way, when the gui (X in this case) exits for any reason, then the
>> console shell session logs out automatically.
>>
>> That's fine, but requires more typing, and remembering to add the
>> extra "; exit" command.
>>
>> So to optimize, simply put the sequency "startx; exit" (or similar)
>> into a shell function - I use the name "se" since it's less to type :)
>>
>> So now I use:
>> a) log in to Linux console
>> b) se
>>
>> Happy and safe sessions to all,
>> Zenaan
>
> Outstanding! I'm going to start doing that. Thanks.

You're welcome.

> What shellscript contains the se function on your system?

My system is not relevant. The point is, it needs to be in one of your
startup scripts. If you use the GNU Bash shell, then you might try
~/.bashrc

Other shells might have different function declaration syntax, and
different put-this-function-in-my-environment syntax.

I have attached my ~/lib/libintrospect.sh file and added the se
function to the bottom, so you can see how this works for bash,
including a function which can be used to export all declared
functions - you may of course only want to export one or two
functions, but at least this shows you how to do that.

I plan to tidy up my bash libraries and upload them - hopefully this year.


> Of course, if a badguy has physical access, then you're pretty much
> screwed anyway: If you don't have a bios password they can boot System
> Rescue CD, mount your root partition, delete the x in the second field
> of root's record (or your record if there's no root), log in, press
> enter, log in, change the password to something they like, and have
> their way with the machine.

Of course. This is simply one extra layer of protection, and will only
protect you against a quick-and-dirty type attach which might
otherwise be done in just a few seconds. This script can prevent that
type of physical-access attack, so it's much better than nothing.

Enjoy,
Zenaan


libintrospect.sh
Description: Bourne shell script

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Steve Litt of Troubleshooters.Com]

On Thu, 20 Mar 2014 12:44:21 +1100
Zenaan Harkness  wrote:

> > Yeah, when making a machine for a less technical or less
> > command-prompt comfortable person, I like to have it boot into GUI
> > via the desktop manager. But when setting it up for myself or for
> > people technically sharp enough to log in and then type
> > "startx" (and people you can trust with the command prompt), I like
> > to boot to the command prompt.
> 
> When logging in at the Linux console (on current kernels at least),
> then running startx, there is a security problem:
> 
> Anyone with physical access to your computer could:
> 
> a) logout of your gui session (if it's not screensaver locked), taking
> them back to your command line, and depending on your settings of
> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
> man sudoers) might give them instant root access;
> either way, mischief may ensure.
> 
> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
> session, notwithstanding if you even have it gui locked
> 
> 
> SO: what to do?
> 
> What I did for a while was:
> a) log in to Linux console
> b) startx; exit
> 
> This way, when the gui (X in this case) exits for any reason, then the
> console shell session logs out automatically.
> 
> That's fine, but requires more typing, and remembering to add the
> extra "; exit" command.
> 
> So to optimize, simply put the sequency "startx; exit" (or similar)
> into a shell function - I use the name "se" since it's less to type :)
> 
> So now I use:
> a) log in to Linux console
> b) se
> 
> Happy and safe sessions to all,
> Zenaan

Outstanding! I'm going to start doing that. Thanks.

What shellscript contains the se function on your system?

Of course, if a badguy has physical access, then you're pretty much
screwed anyway: If you don't have a bios password they can boot System
Rescue CD, mount your root partition, delete the x in the second field
of root's record (or your record if there's no root), log in, press
enter, log in, change the password to something they like, and have
their way with the machine.

But I still like your se, and will do that.

Thanks,

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140319224849.1b1aaec5@mydesk

Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Zenaan Harkness]

> Yeah, when making a machine for a less technical or less command-prompt
> comfortable person, I like to have it boot into GUI via the desktop
> manager. But when setting it up for myself or for people technically
> sharp enough to log in and then type "startx" (and people you can
> trust with the command prompt), I like to boot to the command prompt.

When logging in at the Linux console (on current kernels at least),
then running startx, there is a security problem:

Anyone with physical access to your computer could:

a) logout of your gui session (if it's not screensaver locked), taking
them back to your command line, and depending on your settings of
/etc/sudoers tty_tickets or respectively !tty_tickets setting - see
man sudoers) might give them instant root access;
either way, mischief may ensure.

b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
session, notwithstanding if you even have it gui locked


SO: what to do?

What I did for a while was:
a) log in to Linux console
b) startx; exit

This way, when the gui (X in this case) exits for any reason, then the
console shell session logs out automatically.

That's fine, but requires more typing, and remembering to add the
extra "; exit" command.

So to optimize, simply put the sequency "startx; exit" (or similar)
into a shell function - I use the name "se" since it's less to type :)

So now I use:
a) log in to Linux console
b) se

Happy and safe sessions to all,
Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caosgnssdt+5w-teaijnkfnkl0tmclf4ljuiokkw+oxdfiei...@mail.gmail.com

Re: Startx: was Great Debian experience

[Lisi Reisz]

On Wednesday 19 March 2014 15:50:41 Steve Litt of Troubleshooters.Com 
wrote:
> And last but
> not least, booting to CLI and using startx gives me that nostalgic
> feeling for when I was a young whippersnapper using Red Hat 5.1.

:-)

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201403191616.13703.lisi.re...@gmail.com

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Zenaan Harkness]

On 1/3/14, Brian  wrote:
> On Fri 03 Jan 2014 at 16:28:05 +1100, Zenaan Harkness wrote:
>> On 12/13/13, Zenaan Harkness  wrote:
>> >
>> > Clearly consolekit is started (logout, as well as reboot etc now
>> > work), my keyboard shortcuts work etc.
>> >
>> > This seems ideal - no per-user configuration, and it just works
>> > (TM)(C)(R).
>>
>> This stopped working after a recent upgrade, since I too quickly
>> allowed apt to overwrite my change in /etc/pam.d/common-session
>
> Practise safe upgrading; always say 'no'.

:)

My thinking is usually "I'm running sid, feedback re default config is
sometimes useful to the project and therefore benefits go beyond
myself, for a little short term pain".


> >From pam-auth-update(8):
>
>If the user specifies that pam-auth-update should override
>local configuration changes, the locally-modified files will
>be saved in /etc/pam.d/ with a suffix of .pam-old.
>
> Any sign of .pam-old files?

Yes, common-session.pam-old is right there, with the "missing" line.

>> Is there any reason that the following, from
>> /usr/share/doc/xfce4-session/README.Debian :
>>
>>* install libpam-ck-connector
>>* put:
>>
>>
>>session   optional  pam_loginuid.so
>>
>>
>>*before* pam_ck_connector.so in /etc/pam.d/common-session.
>>
>> is _not_ part of the default install for Debian?
>
> Consolekit may not be on the system.

That's the point - this line:

  session optionalpam_ck_connector.so nox11

was already there;
I had to add the following line:

  session optionalpam_loginuid.so

I'm wondering why this line (directly above) cannot be included by
default - it does say "optional" after all ???


>> $ dpkg -S /etc/pam.d/common-session
>> dpkg-query: no path found matching pattern /etc/pam.d/common-session
>>
>> I guess it must be generated by a script or something. What's the
>> process or rather command line command for determining which script
>> created a particular file such as this one?
>
>brian@desktop:~$ dpkg -S common-session

Ahh thank you. dpkg -S, but with "basename" not fully qualified path.

>libpam-runtime: /usr/share/pam/common-session.md5sums
>libpam-runtime: /usr/share/pam/common-session-noninteractive.md5sums
>libpam-runtime: /usr/share/pam/common-session
>libpam-runtime: /usr/share/pam/common-session-noninteractive
>
> libpam-runtime's postinst script copies /usr/share/pam/common-session to
> /etc/pam.d/common-session.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOsGNSSZOdZ9fYgPPpU=d-W40Y31xEc2u=+aRs_d2W=ctt6...@mail.gmail.com

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Brian]

On Fri 03 Jan 2014 at 16:28:05 +1100, Zenaan Harkness wrote:

> On 12/13/13, Zenaan Harkness  wrote:
> >
> > Clearly consolekit is started (logout, as well as reboot etc now
> > work), my keyboard shortcuts work etc.
> >
> > This seems ideal - no per-user configuration, and it just works (TM)(C)(R).
> 
> This stopped working after a recent upgrade, since I too quickly
> allowed apt to overwrite my change in /etc/pam.d/common-session

Practise safe upgrading; always say 'no'.

>From pam-auth-update(8):

   If the user specifies that pam-auth-update should override
   local configuration changes, the locally-modified files will
   be saved in /etc/pam.d/ with a suffix of .pam-old.

Any sign of .pam-old files?
 
> Is there any reason that the following, from
> /usr/share/doc/xfce4-session/README.Debian :
> 
>* install libpam-ck-connector
>* put:
> 
>
>session   optional  pam_loginuid.so
>
> 
>*before* pam_ck_connector.so in /etc/pam.d/common-session.
> 
> is _not_ part of the default install for Debian?

Consolekit may not be on the system.

> $ dpkg -S /etc/pam.d/common-session
> dpkg-query: no path found matching pattern /etc/pam.d/common-session
> 
> I guess it must be generated by a script or something. What's the
> process or rather command line command for determining which script
> created a particular file such as this one?

   brian@desktop:~$ dpkg -S common-session
   libpam-runtime: /usr/share/pam/common-session.md5sums
   libpam-runtime: /usr/share/pam/common-session-noninteractive.md5sums
   libpam-runtime: /usr/share/pam/common-session
   libpam-runtime: /usr/share/pam/common-session-noninteractive

libpam-runtime's postinst script copies /usr/share/pam/common-session to
/etc/pam.d/common-session.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140103111927.gj5...@copernicus.demon.co.uk

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Zenaan Harkness]

On 12/13/13, Zenaan Harkness  wrote:
> On 12/13/13, Brian  wrote:
>> On Thu 12 Dec 2013 at 17:23:31 +1100, Zenaan Harkness wrote:
>>
>>> What seemed like a good idea, at, the, time ... is longer looking so
>>> good. Any ideas why this odd behaviour would appear as it does?
>>
>> You could try following the advice given in
>>
>>/usr/share/doc/xfce4-session/README.Debian
>
> This is excellent advice.
>
> Please Note: before these experiments, I simply had ~/.xinitrc, and
> startx worked.
>
> However, I was inspired by what is the new/current "debian way".
>
> On a whim, I removed ~/.xinitrc and ~/.xsession and I have no ~/.xsessionrc
> .
>
> So now things work as well as they did with ~/.xinitrc , but without
> any ~/.x* files! This is good.
>
> Clearly consolekit is started (logout, as well as reboot etc now
> work), my keyboard shortcuts work etc.
>
> This seems ideal - no per-user configuration, and it just works (TM)(C)(R).

This stopped working after a recent upgrade, since I too quickly
allowed apt to overwrite my change in /etc/pam.d/common-session

Is there any reason that the following, from
/usr/share/doc/xfce4-session/README.Debian :

   * install libpam-ck-connector
   * put:

   
   session   optional  pam_loginuid.so
   

   *before* pam_ck_connector.so in /etc/pam.d/common-session.

is _not_ part of the default install for Debian?

$ dpkg -S /etc/pam.d/common-session
dpkg-query: no path found matching pattern /etc/pam.d/common-session

I guess it must be generated by a script or something. What's the
process or rather command line command for determining which script
created a particular file such as this one?

TIA
Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOsGNSSjOzuGbyf=2d=B3RkcCuHmtcnWjb91BPGmOs=4+hp...@mail.gmail.com

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Vincent Lefevre]

On 2013-12-12 00:21:18 -0700, Bob Proulx wrote:
>   2.1 xdm graphical login manager (or gdm, or kdm, or lightdm, or other)
>  Runs /etc/X11/Xsession
> Redirects output to .xsession-errors
[...]

Not for gdm3 3.5.2+. $XDG_CACHE_HOME/gdm/session.log is now used,
but this is currently a bit confidential. :) See:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691498
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729574

about the changes that need to be done in the documentation.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131229003255.ga32...@xvii.vinc17.org

Re: startx (with no per-user config) works, kdm has _issues_

[Brian]

On Mon 16 Dec 2013 at 11:32:02 +1100, Zenaan Harkness wrote:

> On 12/16/13, Brian  wrote:
> >
> > I gave kdm a quick whirl with Xfce on Wheezy. No problem (I only tested
> > ALT-F2), but no advice for you either.
> 
> It seems that, for me, a shortcut involving the "Windows Logo" key
> does not work. Would you mind testing that for me please?

The default shortcut for the command 'xfce4-display-settings --minimal'
is 'p' here. It does not work with startx or kdm. When '--minimal'
is removed from xfce4-keyboard-shortcuts the shortcut works with both.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/16122013135410.aa6739a81...@desktop.copernicus.demon.co.uk

Re: FVWM + ( Re: startx + ~/.xsession and no ~/.xinitrc, or .xsessionrc )

[Brian]

On Mon 16 Dec 2013 at 17:17:01 +1300, Chris Bannister wrote:

> On Sat, Dec 14, 2013 at 08:25:56PM +, Brian wrote:
> > 
> > Put
> > 
> >exec fvwm
> > 
> > after the xterm command in .xsession. This command does not complete and
> > .xsession doesn't close. You've summoned X, give it a chance to show off
> > what it can do :).
> > 
> > EXERCISE: You decide 'exec fvwm' is a splendid idea but decide to keep
> > your .xsessionrc and put the extra line in it. Discuss the consequences.
> 
> :)

Good effort! :)

40x11-common_xsessionrc will hang at the 'exec fvwm' command. This is ok
if all you want is a fvwm managed desktop. However, the subsequent
commands in /etc/X11/Xsession.d will then not be sourced. This could
spell disaster for someone who wanted consolekit or ssh-agent to be set
up.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/16122013102626.6c8d598a5...@desktop.copernicus.demon.co.uk

FVWM + ( Re: startx + ~/.xsession and no ~/.xinitrc, or .xsessionrc )

[Chris Bannister]

On Sat, Dec 14, 2013 at 08:25:56PM +, Brian wrote:
> 
> Put
> 
>exec fvwm
> 
> after the xterm command in .xsession. This command does not complete and
> .xsession doesn't close. You've summoned X, give it a chance to show off
> what it can do :).
> 
> EXERCISE: You decide 'exec fvwm' is a splendid idea but decide to keep
> your .xsessionrc and put the extra line in it. Discuss the consequences.

:)

renamed .xsessionrc to .xsession and added exec fvwm as last line.
All good now, cheers! 

For some reason I thought the 'exec fvwm' command was no longer
necessary, but as someone has already mentioned I could ditch the
.xsession* file(s) completely. This would mean moving the background
handling into the .fvwm/config file, which would be the 'cleaner'
solution.

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


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131216041701.GC8938@tal

Re: startx (with no per-user config) works, kdm has _issues_

[Zenaan Harkness]

On 12/16/13, Brian  wrote:
> On Sun 15 Dec 2013 at 11:27:26 +1100, Zenaan Harkness wrote:
>
>> On 12/13/13, Zenaan Harkness  wrote:
>> > So I have no per-user config, such as ~/.xinitrc , ~/.xsession and
>> > ~/.xsessionrc .
>> >
>> > startx after linux console login works well.
>>
>> That is, to start xfce
>>
>> > When I login to Linux console, then run
>> > sudo service kdm start, and then login from there to xfce,
>> > my XFCE4 keyboard shortcuts don't work (Settings -> Keyboard ->
>> > Application Shortcuts).
>>
>> Is it reasonable, or unreasonable, to use KDM as my graphical login
>> manager to log in to XFCE4?
>
> I gave kdm a quick whirl with Xfce on Wheezy. No problem (I only tested
> ALT-F2), but no advice for you either.

It seems that, for me, a shortcut involving the "Windows Logo" key
does not work. Would you mind testing that for me please?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caosgnst_ocwd-x9v-ot3f7zl0q0+vd1iicaesafb-mtn0ac...@mail.gmail.com

Re: startx (with no per-user config) works, kdm has _issues_

[Brian]

On Sun 15 Dec 2013 at 11:27:26 +1100, Zenaan Harkness wrote:

> On 12/13/13, Zenaan Harkness  wrote:
> > So I have no per-user config, such as ~/.xinitrc , ~/.xsession and
> > ~/.xsessionrc .
> >
> > startx after linux console login works well.
> 
> That is, to start xfce
> 
> > When I login to Linux console, then run
> > sudo service kdm start, and then login from there to xfce,
> > my XFCE4 keyboard shortcuts don't work (Settings -> Keyboard ->
> > Application Shortcuts).
> 
> Is it reasonable, or unreasonable, to use KDM as my graphical login
> manager to log in to XFCE4?

I gave kdm a quick whirl with Xfce on Wheezy. No problem (I only tested
ALT-F2), but no advice for you either.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/15122013152103.b7b6d7d96...@desktop.copernicus.demon.co.uk

Re: startx (with no per-user config) works, kdm has _issues_

[Zenaan Harkness]

On 12/13/13, Zenaan Harkness  wrote:
> So I have no per-user config, such as ~/.xinitrc , ~/.xsession and
> ~/.xsessionrc .
>
> startx after linux console login works well.

That is, to start xfce

> When I login to Linux console, then run
> sudo service kdm start, and then login from there to xfce,
> my XFCE4 keyboard shortcuts don't work (Settings -> Keyboard ->
> Application Shortcuts).

Is it reasonable, or unreasonable, to use KDM as my graphical login
manager to log in to XFCE4?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caosgnss-ttrb5nrcmkb0kcusj33p0ce1hfobketrreadu++...@mail.gmail.com

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Brian]

On Sun 15 Dec 2013 at 06:29:52 +1300, Chris Bannister wrote:

> JFTR, I am running FVWM and have the following:
> tal% less .xsessionrc
> /home/chrisb/background.sh &
> 
> xterm -fn 10x20 -xrm "XTerm.vt100.background: #CCA8AA" -xrm \
>   "XTerm.vt100.foreground: blue" -geom 120x15 &
> tal%

You start an xterm. Remember that a script executes each line
sequentially and only moves on to the next line if the previous command
completes.

The xterm is put in the background; the command has completed. There is
no next line in .xsessionrc so /etc/X11/Xsession moves on from
40x11-common_xsessionrc to 50x11-common_determine-startup. Here it first
looks for ~/.xsession. You haven't got one so it goes on to investigate
/usr/bin/x-window-manager. This file links to x-window-manager in
/etc/alternatives. I bet this points to fvwm in your case!

All is right with the world; so you think :).

> I use startx. If I rename .xsessionrc to .xsession then X bails out 
> on starting and I am returned back to the prompt.

>From xinit(1)

   The xinit program is used to start the X Window System server
   and a first client program . . . 

Once that client program completes execution xinit exits; that is, X
goes away.

Your .xsession contains a single backgrounded command. Guess what?

[Snip]

> So it seems I'm going to have to go through the startup sequence *again*
> and try to figure out why X/FVWM won't start with a .xsession file. :(

Put

   exec fvwm

after the xterm command in .xsession. This command does not complete and
.xsession doesn't close. You've summoned X, give it a chance to show off
what it can do :).

> Thanks Brian for putting me on the right path, although it is with mixed
> blessings :) 

Bob Proulx posts were the inspiration. Although I had sorted out the use
of startx to my satisfaction many years ago, his recent mails caused me
to look again at how Debian handled it.

MORAL: ,xsession - good. .xinitrc or .xessionrc - bad (unless you really
know what you are doing and have special needs).

EXERCISE: You decide 'exec fvwm' is a splendid idea but decide to keep
your .xsessionrc and put the extra line in it. Discuss the consequences.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214202556.gn5...@copernicus.demon.co.uk

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Charlie]

On Sun, 15 Dec 2013 06:29:52 +1300 Chris Bannister sent:

> I do remember this issue in the past, a google was not very helpful -
> and may even have been misleading - e.g. suggesting that .xsessionrc 
> was the correct file to use. And since .xsession or .xinitrc didn't
> work I must have assumed it was correct.

That would have been the reason why I also changed to ~/.xsessionrc.
Because I was using FVWM at the time and recall that it was documented
somewhere to get X working was to change the file name.

On another note, same topic. In Xfce4 which I'm now using, something
strange happened.

To get my printer working, I changed a few things and then logged out
on the application menu drop down list "Log Out" Then logged back in as
user.

All the things that my ~/.xsession file loaded, came up
again as I would expect. 

However, they came up twice. Two of everything?

I thought it was a glitch. Stopped the computer, did a hard reboot and
it did the same, everything came up twice. So I commented everything
out of my ~/.xsession file except: exec startxfce4

So my system starts as it always did, loading all the applications as
it did when they were so directed in the ~/.xsession file. Nicer in
fact, as it places kalarm in the panel rather than on the desktop from
whence I placed it into the panel. But they were all commented out??

So, it seems using the Xfce4 logout, wrote a file that gets loaded
automagically which returns everything to as it was when X is started
again? But what file?

There is no duplicate ~/.xsession file so there must be a file
elsewhere in the system that Log Out wrote or edited before exiting?

It works well as long as I comment out everything I want loaded at
startup in my ~/.xsession file. But is it a feature or a bug if I
don't know where the file that does is all this is located?

I have been looking through this thread to try to find which file might
be changed but had no luck yet.

Charlie

-- 
Registered Linux User:- 329524
***

Christmas is not a date. It is a state of mind. - Mary Ellen
Chase

***

Debian GNU/Linux - just the best way to create magic

-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131215071705.44f71947@taogypsy.wildlife

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Chris Bannister]

On Thu, Dec 12, 2013 at 02:23:48PM +, Brian wrote:
> On Thu 12 Dec 2013 at 00:21:18 -0700, Bob Proulx wrote:
> 
> > The man page for Xsession documents ~/.xsessionrc and ~/.xsession.  It
> > says that ~/.xsessionrc is only for setting variables and the
> > ~/.xsession is for executing commands.  (But in reality this is a grey
> > area.)
> 
> Let's attempt to get a colour transformation to black and white. :)
> 
> Firstly: .xsessionrc is for holding ***global environment*** variables.
> The emphasis is mine.
> 
> Secondly: 40x11-common_xsessionrc in /etc/X11/Xsession.d is sourced
> before 50x11-common_determine-startup. So .xsessionrc is read before
> .xsession and any environment variables set will become available to
> applications run by the commands in .xsession.
> 
> Thirdly: Everyone likes a test to do. :) Create .xsessionrc with
> contents similar to these:
> 
>xterm &
>TZ='GST-10' ; export TZ
>exec 
> 
> Now execute 'startx'. You have a functioning system? Execute 'date'.
> 
> Putting commands in .xsessionrc is very naughty. Are you still there,
> Charlie? For your own good, please stop doing it.

JFTR, I am running FVWM and have the following:
tal% less .xsessionrc
/home/chrisb/background.sh &

xterm -fn 10x20 -xrm "XTerm.vt100.background: #CCA8AA" -xrm \
  "XTerm.vt100.foreground: blue" -geom 120x15 &
tal%

I use startx. If I rename .xsessionrc to .xsession then X bails out 
on starting and I am returned back to the prompt. 

I had to change .xinitrc to .xsessionrc at some stage in the past when
some system change was altered. I can't remember whether it was an
upgrade of FVWM or an upgrade of X which caused this.

I do remember this issue in the past, a google was not very helpful -
and may even have been misleading - e.g. suggesting that .xsessionrc 
was the correct file to use. And since .xsession or .xinitrc didn't work 
I must have assumed it was correct.

So it seems I'm going to have to go through the startup sequence *again*
and try to figure out why X/FVWM won't start with a .xsession file. :(

Thanks Brian for putting me on the right path, although it is with mixed
blessings :) 

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


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214172952.GC9143@tal

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Bob Proulx]

Brian wrote:
> May we look a little closer at one or two of the things you say?
> 
> Bob Proulx wrote:
> > Because startx does not use .xsession.  You have things criss-crossed.

Oops!  I was definitely wrong with that statement.

> 1. Running startx basically runs xinit.
> 
> 2. startx first looks for ~/.xinitrc which, unless there is a very good
>reason, should not be on a Debian system.
> 
> 3. startx now searches for the system xinitrc in /etc/X11/xinit/. This
>contains the line
> 
>   . /etc/X11/Xsession
> 
>and Xsession will use ~/.xsession if it exists.
> 
> So startx on Debian uses .xsession :). However, it does not consult it
> directly.

Yes.  My bad.  I was confused! :-(  Thanks for the correction.

Bob


signature.asc
Description: Digital signature

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Zenaan Harkness]

On 12/13/13, Brian  wrote:
> On Thu 12 Dec 2013 at 17:23:31 +1100, Zenaan Harkness wrote:
>
>> What seemed like a good idea, at, the, time ... is longer looking so
>> good. Any ideas why this odd behaviour would appear as it does?
>
> You could try following the advice given in
>
>/usr/share/doc/xfce4-session/README.Debian

This is excellent advice.

Please Note: before these experiments, I simply had ~/.xinitrc, and
startx worked.

However, I was inspired by what is the new/current "debian way".

On a whim, I removed ~/.xinitrc and ~/.xsession and I have no ~/.xsessionrc .

So now things work as well as they did with ~/.xinitrc , but without
any ~/.x* files! This is good.

Clearly consolekit is started (logout, as well as reboot etc now
work), my keyboard shortcuts work etc.

This seems ideal - no per-user configuration, and it just works (TM)(C)(R).

Thanks
Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOsGNSQKciExJDwZB12QTbQQ1Md2JsJMYkYyH0==-ij=vls...@mail.gmail.com

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Charlie]

On Thu, 12 Dec 2013 19:13:50 + Brian sent:

> [When talking about .xsessionrc versus .xsession]
> 
> > I might just revert it back to ~/.xsession and see what error
> > messages I receive, if any?  
> 
> You won't get any error messages. The system will execute valid
> commands in .xessionrc just as well as does those in .xsession.
> Whether the system is at rights with itself is a different matter.

As your say, no errors.

Charlie

-- 
Registered Linux User:- 329524
***

One reason I don't drink is that I want to know when I'm having
a good time. - Lady Astor

***

Debian GNU/Linux - just the best way to create magic

-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131213083104.3abb6e8c@taogypsy.wildlife

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Charlie]

On Thu, 12 Dec 2013 14:23:48 + Brian sent:

> Putting commands in .xsessionrc is very naughty. Are you still there,
> Charlie? For your own good, please stop doing it.

I've renamed the file to ~/.xsession after reading the information Bob
kindly supplied and it's all working great, as normal.

Thanks,
Charlie
-- 
Registered Linux User:- 329524
***

A dream grants what one covets when awake. - German proverb

***

Debian GNU/Linux - just the best way to create magic

-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131213082604.2a2e5ae2@taogypsy.wildlife

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Brian]

On Thu 12 Dec 2013 at 17:47:12 +1100, Charlie wrote:

> I'm happy with what happens when I boot my system - same as when I
> used .xsessionrc with FVWM. But will look into it and read a bit when
> time permits. I could be doing the wrong thing entirely.

You are. But you will never know until you encounter a problem and don't
recognise it as a misunderstanding of what Debian's X configuration is
intended to do.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/12122013192326.d4bc8a2b1...@desktop.copernicus.demon.co.uk

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Brian]

On Thu 12 Dec 2013 at 22:18:31 +1100, Charlie wrote:

[When talking about .xsessionrc versus .xsession]

> I might just revert it back to ~/.xsession and see what error messages
> I receive, if any?

You won't get any error messages. The system will execute valid commands
in .xessionrc just as well as does those in .xsession. Whether the
system is at rights with itself is a different matter.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/12122013190637.267509b6e...@desktop.copernicus.demon.co.uk

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Brian]

On Thu 12 Dec 2013 at 19:06:41 +1100, Zenaan Harkness wrote:

> I have been trying to get a setup that works properly with startx, as
> well as with kdm. Do you have a recommendation as to how best to

Your original query concerned startx only. You have now escalated the
problem to include kdm :). I'm unsure that helps.

> I have experimented with a couple combinations, but there are too many.

Keep .xsession as a contant. You know it makes sense.

> I have at the moment, startx working well, with .xinitrc and .xsession
> both linking to the same file (bash script, with my "exec ..." line).

The mind boggles! :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/12122013183708.45a193383...@desktop.copernicus.demon.co.uk

Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)

[Brian]

May we look a little closer at one or two of the things you say?

On Wed 11 Dec 2013 at 23:36:51 -0700, Bob Proulx wrote:

> Because startx does not use .xsession.  You have things criss-crossed.

1. Running startx basically runs xinit.

2. startx first looks for ~/.xinitrc which, unless there is a very good
   reason, should not be on a Debian system.

3. startx now searches for the system xinitrc in /etc/X11/xinit/. This
   contains the line

  . /etc/X11/Xsession

   and Xsession will use ~/.xsession if it exists.

So startx on Debian uses .xsession :). However, it does not consult it
directly.

>   $ grep xsession /usr/bin/startx
>   ... nothing shown ...

   grep xinit /usr/bin/startx

> The xsession script is only used by the xdm, gdm, gdm3, kdm, lightdm X
> Display Manager graphical login manager programs because they all call
> the /etc/X11/Xsession script.

Please see above.

> Yes, because startx does use xinitrc. 

Indeed it does. It goes on to use /etc/X11/Xsession. :)

> If you are using startx then yes you should use xinitrc.  Only use the
> xsession or xsessionrc file (either one) if you are using one of the
> graphical login managers such as xdm, gdm, gdm3, kdm, lightdm.

Should some of the xs have a '.' in front of them? startx and .xsession
should (except in exceptional circunstances) be found together. A good
way to foul a system up is to use .xinitrc or .xsessionrc by itself with
startx because the files in /etc/X11/Xsession.d then do not get used.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131212175255.gl5...@copernicus.demon.co.uk