Processed: Re: Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

2020-01-23 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 grave
Bug #949698 [elogind] elogind: deletes users’ files under /dev/shm/ on logout
Severity set to 'grave' from 'important'

-- 
949698: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949698
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

2020-01-23 Thread Mark Hindley
Control: severity -1 important

Thorsten,

On Thu, Jan 23, 2020 at 10:10:03PM +0100, Thorsten Glaser wrote:
> > This behaviour is configurable via RemoveIPC in /etc/elogind/logind.conf. 
> > See
> 
> > Perhaps you could confirm that this configuration change provides the 
> > behaviour
> > you want?
> 
> thanks, yes, this provides the behaviour necessary for proper system
> operation. Please make it the default.

Good!

Downgrading severity to important.

I will explore the implications of changing the default.

Thanks.

Mark



Processed: Re: Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

2020-01-23 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 important
Bug #949698 [elogind] elogind: deletes users’ files under /dev/shm/ on logout
Severity set to 'important' from 'critical'

-- 
949698: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949698
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

2020-01-23 Thread Thorsten Glaser
Hi Mark,

> This behaviour is configurable via RemoveIPC in /etc/elogind/logind.conf. See

> Perhaps you could confirm that this configuration change provides the 
> behaviour
> you want?

thanks, yes, this provides the behaviour necessary for proper system
operation. Please make it the default.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

2020-01-23 Thread Mark Hindley
On Thu, Jan 23, 2020 at 08:32:46PM +0100, Thorsten Glaser wrote:
> Package: elogind
> Version: 241.3-1+debian2
> Severity: critical
> Justification: breaks unrelated software
> 
> I’m using a scheme in which I store ssh-agent and gpg-agent information
> across all logins (local X session or ssh or xrdp) under /dev/shm/ since
> I needed space that an unprivileged user can use and that doesn’t persist
> across reboots.
> 
> Since installing elogind, logging out from SSH sessions then on again
> both breaks gpg-agent as well as makes ssh-agent instances multiply and,
> thus, lose their loaded keys to the user.

Thorsten,

Thanks for this.

This behaviour is configurable via RemoveIPC in /etc/elogind/logind.conf. See
man logind.conf(5).

I accept that the documentation for the behaviour is difficult to find (I had to
search quite hard) and it may be that the default ought to be different.

Perhaps you could confirm that this configuration change provides the behaviour
you want?

Many thanks.

Mark



Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

2020-01-23 Thread Thorsten Glaser
On Thu, 23 Jan 2020, Dolphin Oracle wrote:

> should you not be using /tmp for that rather that /dev/shm?

No, /tmp is not guaranteed to be tmpfs and so can persist across boots.
On a moderate wide scale of GNU/Linux installations /dev/shm is the
(only) location that fits my (modest — we’re talking about several dozen
bytes and a FIFO or two) needs.

> I think /tmp should be set up as a tmpfs and will then not persist across

Yes, but that’s a local admin choice, and it often is not because some
“enterprise” software writes a lot into it and does not use /var/tmp for
large content.


But that’s besides the question. This behaviour is a grave bug because:

> > logged out from all ssh sessions. In particular, this will also break
> > software that runs as the user, dæmonised, that uses shared memory.

This is inacceptable.


In the meantime, someone told me…

> > If you have to clean up after yourselves, keep a list and track of the
> > files you created and will later need to delete.
> >
> > It might be a good idea to see whether systemd does the same and, if

… that They don’t do that, au contraire, they often leave tons of crap
around in /dev/shm…

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

2020-01-23 Thread Dolphin Oracle
should you not be using /tmp for that rather that /dev/shm?

I think /tmp should be set up as a tmpfs and will then not persist across
reboots.  /var/tmp is for tmp space that needs to persist across reboots.



On Thu, Jan 23, 2020 at 2:36 PM Thorsten Glaser  wrote:

> Package: elogind
> Version: 241.3-1+debian2
> Severity: critical
> Justification: breaks unrelated software
>
> I’m using a scheme in which I store ssh-agent and gpg-agent information
> across all logins (local X session or ssh or xrdp) under /dev/shm/ since
> I needed space that an unprivileged user can use and that doesn’t persist
> across reboots.
>
> Since installing elogind, logging out from SSH sessions then on again
> both breaks gpg-agent as well as makes ssh-agent instances multiply and,
> thus, lose their loaded keys to the user.
>
> Tons of searching and debugging eventuall led me, with strace as root on
> it, to the culprit: elogind
>
> lrwxrwxrwx 1 root root 0 Jan 23 20:21 /proc/3061/exe ->
> /lib/elogind/elogind*
>
> 3061  unlinkat(22, "info2", 0)  = 0
> 3061  unlinkat(21, ".ssh-2339", AT_REMOVEDIR) = 0
>
>
> Cease that instantly. This breaks unrelated software on the system,
> considering that the user’s processes are still running, even if they
> logged out from all ssh sessions. In particular, this will also break
> software that runs as the user, dæmonised, that uses shared memory.
>
> If you have to clean up after yourselves, keep a list and track of the
> files you created and will later need to delete.
>
> It might be a good idea to see whether systemd does the same and, if
> so, clone this bugreport and assign the clone to them. I’m not running
> systemd, so I can’t do that myself easily.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500,
> 'unstable'), (100, 'experimental')
> Architecture: x32 (x86_64)
> Foreign Architectures: i386, amd64
>
> Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
>
> Versions of packages elogind depends on:
> ii  dbus 1.12.16-2
> ii  debconf  1.5.73
> ii  libacl1  2.2.53-5
> ii  libc62.29-9
> ii  libcap2  1:2.27-1
> ii  libelogind0  241.3-1+debian2
> ii  libselinux1  3.0-1
> ii  libudev1 244-3
> ii  lsb-base 11.1.0
>
> Versions of packages elogind recommends:
> ii  libpam-elogind  241.3-1+debian2
> ii  policykit-1 0.105-26
>
> elogind suggests no packages.
>
> -- no debconf information
>


Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

2020-01-23 Thread Thorsten Glaser
Package: elogind
Version: 241.3-1+debian2
Severity: critical
Justification: breaks unrelated software

I’m using a scheme in which I store ssh-agent and gpg-agent information
across all logins (local X session or ssh or xrdp) under /dev/shm/ since
I needed space that an unprivileged user can use and that doesn’t persist
across reboots.

Since installing elogind, logging out from SSH sessions then on again
both breaks gpg-agent as well as makes ssh-agent instances multiply and,
thus, lose their loaded keys to the user.

Tons of searching and debugging eventuall led me, with strace as root on
it, to the culprit: elogind

lrwxrwxrwx 1 root root 0 Jan 23 20:21 /proc/3061/exe -> /lib/elogind/elogind*

3061  unlinkat(22, "info2", 0)  = 0
3061  unlinkat(21, ".ssh-2339", AT_REMOVEDIR) = 0


Cease that instantly. This breaks unrelated software on the system,
considering that the user’s processes are still running, even if they
logged out from all ssh sessions. In particular, this will also break
software that runs as the user, dæmonised, that uses shared memory.

If you have to clean up after yourselves, keep a list and track of the
files you created and will later need to delete.

It might be a good idea to see whether systemd does the same and, if
so, clone this bugreport and assign the clone to them. I’m not running
systemd, so I can’t do that myself easily.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages elogind depends on:
ii  dbus 1.12.16-2
ii  debconf  1.5.73
ii  libacl1  2.2.53-5
ii  libc62.29-9
ii  libcap2  1:2.27-1
ii  libelogind0  241.3-1+debian2
ii  libselinux1  3.0-1
ii  libudev1 244-3
ii  lsb-base 11.1.0

Versions of packages elogind recommends:
ii  libpam-elogind  241.3-1+debian2
ii  policykit-1 0.105-26

elogind suggests no packages.

-- no debconf information