On 01/04/2012 10:24 PM, Axel Beckert wrote:
Hi Simon,
Simon McVittie wrote:
On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
On Mon, 02 Jan 2012, Axel Beckert wrote:
/tmp is a good choice because the next reboot will automatically clean
up everything (and
disclaimerI didn't try it/disclaimer
Would that one help?
https://github.com/nelhage/reptyr
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Hi,
Thomas Goirand wrote:
disclaimerI didn't try it/disclaimer
As mentioned somewhere else in the thread I did once try either retty
or reptyr (can't remember) and it didn't work very well.
https://github.com/nelhage/reptyr
It's also packaged for Debian. :-)
I though think it's a not so
]] Axel Beckert
I see the following options:
[...]
Not really a serious suggestion, but for completeness
E) ignore the problem and just let people rescue the programs stuck in
the old screen using retty, reptyr or similar.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who
Hi Tollef,
Tollef Fog Heen wrote:
Not really a serious suggestion, but for completeness
E) ignore the problem and just let people rescue the programs stuck in
the old screen using retty, reptyr or similar.
My experiences with one of these tools (IIRC retty, but I'm not sure)
a few years ago
On Tue, Jan 03, 2012 at 04:04:04PM +0100, Axel Beckert wrote:
Hi,
Roger Leigh wrote:
[/tmp mounted noexec]
/run/shm (IIRC formerly /dev/shm) likely would be an
alternative option, too.
No, it would not. This directory is reserved for the eglibc
POSIX SHM/SEM interfaces.
On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
On Mon, 02 Jan 2012, Axel Beckert wrote:
/tmp is a good choice because the next reboot will automatically clean
up everything (and obviously the old binary will not be needed after
a reboot).
Thank you Axel for your
Hi Simon,
Simon McVittie wrote:
On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
On Mon, 02 Jan 2012, Axel Beckert wrote:
/tmp is a good choice because the next reboot will automatically clean
up everything (and obviously the old binary will not be needed after
a
Axel Beckert a...@debian.org wrote:
Simon McVittie wrote:
Would it be enough for the your old screen binary is
/tmp/screen-yhpoe8r/screen notice to also say if your /tmp is mounted
noexec, you might need to copy it elsewhere to run it?
That's my current plan -- with the noexec notice just
On Tue, Jan 03, 2012 at 07:17:04AM +0100, Axel Beckert wrote:
Hi Yaroslav!
Yaroslav Halchenko wrote:
I strongly recommend this solution, along with a proper debconf notice.
[...]
/tmp is a good choice because the next reboot will automatically clean
up everything (and obviously
On Tue, Jan 03, 2012 at 10:05:46AM +, Roger Leigh wrote:
If you really need to use a filesystem mounted noexec, just run
the binary via /lib/ld.so (you'll need to get the real location
from e.g. ldd). Something like:
The kernel does not allow executable mappings from noexec filesystems,
just thought of it: another possible complication of this approach (mv
/usr/bin/screen /tmp/screen-4.0) might be -- tools depending on
screen (e.g. byobu) might be in the cold water if the default screen in
the PATH cannot do its duties.
FWIW:
$ apt-cache rdepends screen
screen
Reverse Depends:
On Jan 03, Yaroslav Halchenko deb...@onerussian.com wrote:
just thought of it: another possible complication of this approach (mv
/usr/bin/screen /tmp/screen-4.0) might be -- tools depending on
screen (e.g. byobu) might be in the cold water if the default screen in
the PATH cannot do its
Hi,
Roger Leigh wrote:
[/tmp mounted noexec]
/run/shm (IIRC formerly /dev/shm) likely would be an
alternative option, too.
No, it would not. This directory is reserved for the eglibc
POSIX SHM/SEM interfaces.
Thanks for this explanation. It's the first time I read or hear about
the
On Tue, 3 Jan 2012, Marco d'Itri wrote:
It does not matter, this is needed strictly for the time of the upgrade
process.
Just how short do you expect this to be? I'm sure many of us dist-upgrade
daily and (shock! horror!) don't reboot after each upgrade. We also don't
expect existing
On Jan 03, Axel Beckert a...@debian.org wrote:
Thanks for the comment. Cc'ing the relevant bug again, as this is
crucial information when I work on fixing the bug.
If /tmp is noexec then the administrator mounted it this way and knows
about it. So if he is smart enought to mount /tmp noexec
On Jan 03, Edward Allcutt edw...@allcutt.me.uk wrote:
On Tue, 3 Jan 2012, Marco d'Itri wrote:
It does not matter, this is needed strictly for the time of the upgrade
process.
Just how short do you expect this to be? I'm sure many of us
dist-upgrade daily and (shock! horror!) don't reboot
Hi,
Marco d'Itri wrote:
If /tmp is noexec then the administrator mounted it this way and knows
about it.
Yeah, but that is possibly such a long time ago that it's not the
first thought. So a small hint to fresh up the memory can't be bad.
So if he is smart enought to mount /tmp noexec then
Le mardi, 3 janvier 2012 16.58:08, Axel Beckert a écrit :
Hi,
Marco d'Itri wrote:
If /tmp is noexec then the administrator mounted it this way and knows
about it.
Another idea would be to use /usr/bin as temporary place for the old screen.
That would be a Policy violation but not a much
On Jan 03, Didier Raboud o...@debian.org wrote:
3) In a screen-cleanup init script, test the inexistance of the flag and
the
existance of /usr/bin/screen-old; in that case, `rm` it.
(+ appropriate version and sanity checks, + idempotency)
This is bad, because to solve a possible 30
Yaroslav Halchenko deb...@onerussian.com writes:
Thank you Axel for your detailed response and IMHO this is indeed close
to an ideal (lightweight, self-cleaning, etc) resolution for this
scenario.
Of course the real lightweight, self-cleaning solution is to not do
anything special as the old
* Romain Francoise rfranco...@debian.org, 2012-01-02, 09:28:
3) Tell people via the release notes that they should not run the
dist-upgrade inside screen, but inside tmux instead.
Unfortunately tmux has an issue of its own for squeeze → wheezy
upgrades, the socket path was changed from
Jakub Wilk jw...@debian.org writes:
Also, you just introduced a security hole: every user can DoS other one
(including root) my mkdiring /tmp/tmux-${VICTIM_UID}.
See #620304 (and CVE-2011-1496) for more context about this.
--
Romain Francoise rfranco...@debian.org
Hi,
Romain Francoise wrote:
Thank you Axel for your detailed response and IMHO this is indeed close
to an ideal (lightweight, self-cleaning, etc) resolution for this
scenario.
Of course the real lightweight, self-cleaning solution is to not do
anything special as the old binary will be
Axel Beckert a...@debian.org writes:
And I can't really execute it, neither as the user owning the screen
session nor as root:
~ # /proc/32039/exe -ls
zsh: permission denied: /proc/32039/exe
Yes, /proc is mounted noexec so you need to use the ld-linux.so trick.
But now that I actually try
On Tue, Jan 3, 2012 at 18:05:22 +0100, Romain Francoise wrote:
Jakub Wilk jw...@debian.org writes:
Also, you just introduced a security hole: every user can DoS other one
(including root) my mkdiring /tmp/tmux-${VICTIM_UID}.
See #620304 (and CVE-2011-1496) for more context about this.
Axel Beckert a...@debian.org writes:
3) Tell people via the release notes that they should not run the
dist-upgrade inside screen, but inside tmux instead.
Unfortunately tmux has an issue of its own for squeeze → wheezy upgrades,
the socket path was changed from /var/run/tmux to /tmp
On Mon, Jan 02, 2012 at 09:28:39AM +0100, Romain Francoise wrote:
Axel Beckert a...@debian.org writes:
3) Tell people via the release notes that they should not run the
dist-upgrade inside screen, but inside tmux instead.
Unfortunately tmux has an issue of its own for squeeze →
On Mon, 02 Jan 2012, Karl Goetz wrote:
to fix a tiny problem which presents itself just for the length of
the upgrade process, if at all.
Correct. It's an option nevertheless, so I mentioned it.
Sorry if I've misunderstood, but doesn't this problem manifest for
*anyone* trying to
Hi,
Romain Francoise wrote:
3) Tell people via the release notes that they should not run the
dist-upgrade inside screen, but inside tmux instead.
Unfortunately tmux has an issue of its own for squeeze → wheezy upgrades,
.oO( Houston, we've got a problem. )
the socket path was
On Mon, Jan 2, 2012 at 03:18:34 +0100, Axel Beckert wrote:
A) Add an option to screen so the screen client speaks the old
protocol to the running server protocol. This IMHO would be best
solution and one without a big impact. It's also something which
could be Debian-only, i.e. a
Hi Julien,
Julien Cristau wrote:
A) Add an option to screen so the screen client speaks the old
protocol to the running server protocol. This IMHO would be best
solution and one without a big impact. It's also something which
could be Debian-only, i.e. a patch. (It of course
On Mon, 02 Jan 2012, Axel Beckert wrote:
I strongly recommend this solution, along with a proper debconf notice.
[...]
/tmp is a good choice because the next reboot will automatically clean
up everything (and obviously the old binary will not be needed after
a reboot).
Thanks for that
On Mon, 2 Jan 2012 09:40:33 -0200
Henrique de Moraes Holschuh h...@debian.org wrote:
On Mon, 02 Jan 2012, Karl Goetz wrote:
to fix a tiny problem which presents itself just for the length
of the upgrade process, if at all.
Correct. It's an option nevertheless, so I mentioned it.
Hi Yaroslav!
Yaroslav Halchenko wrote:
I strongly recommend this solution, along with a proper debconf notice.
[...]
/tmp is a good choice because the next reboot will automatically clean
up everything (and obviously the old binary will not be needed after
a reboot).
Thanks for
Package: wnpp
Severity: normal
Hi,
Debian's screen package needs help with bug triaging, wheezy migration
and upstream lobbying.
Jan took over Debian's screen package in 2007 and was a very active and
talented screen package maintainer. Unfortunately he no more has enough
time[1] to maintain
pardon my blunt question:
but is there really possibility to have them 'fixed'? I am reading
upstream response just as a statement that it can't be achieved due to a
chance in protocol...
On Mon, 02 Jan 2012, Axel Beckert wrote:
Additionally there are a few issues where I'd be happy to have
Hi Yaroslav,
Yaroslav Halchenko wrote:
pardon my blunt question:
No, this question is completely valid and understandable and came up
already in the two mentioned bug reports (#644788 and #649240).
but is there really possibility to have them 'fixed'?
Well, there are several ways to fix
On Jan 02, Axel Beckert a...@debian.org wrote:
A) Add an option to screen so the screen client speaks the old
protocol to the running server protocol. This IMHO would be best
solution and one without a big impact. It's also something which
As long as the needed patch is simple. But if it
Hi Marco,
Marco d'Itri wrote:
1) Let the preinst maintainer script make a copy of the old screen
binary, provide a script to clean up this mess afterwards,
inform the user via debconf about the issue and his
possibilities (where the copy of the old screen is, etc.).
Axel Beckert a...@debian.org writes:
A) Add an option to screen so the screen client speaks the old
protocol to the running server protocol. This IMHO would be best
solution and one without a big impact. It's also something which
could be Debian-only, i.e. a patch. (It of course
Hi Ben,
Ben Finney wrote:
B) Take care that nobody upgrades the screen package while running
inside a screen without being aware of the possible problems. There
are few ideas how to implement this:
1) Mention it in the release notes that screen has to be upgraded
to the
On Mon, 2 Jan 2012 04:13:44 +0100
Axel Beckert a...@debian.org wrote:
Hi Marco,
Marco d'Itri wrote:
2) Make screen 4.0.3 and screen 4.1.0 installable at the same
time, i.e. give them different source and binary package names.
This would require a great amount of work
I fear so,
43 matches
Mail list logo
