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
>>
Hi,
Thomas Goirand wrote:
> I didn't try it
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 good idea to require th
I didn't try it
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: http://lists.debian.org/4f0ad49c.3010...@debian.org
Axel Beckert 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 being
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 aft
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
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 inter
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
]] 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
On Tue, Jan 3, 2012 at 18:05:22 +0100, Romain Francoise wrote:
> Jakub Wilk 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.
>
That d
Axel Beckert 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 it, I realiz
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
Jakub Wilk 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
http://people.debian.org/~rfrancoise/
--
To UNSUBSCRIBE, ema
* Romain Francoise , 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 /var/run/tmux to /tmp in
or
Yaroslav Halchenko 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 binary will be kept
On Jan 03, Didier Raboud 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 minutes issu
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
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
On Jan 03, Edward Allcutt 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 after each
> upgr
On Jan 03, Axel Beckert 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 then he can
proba
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 processe
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
th
On Jan 03, Yaroslav Halchenko 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 duties.
It does not ma
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 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,
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 everythi
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).
On Mon, 2 Jan 2012 09:40:33 -0200
Henrique de Moraes Holschuh 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.
>
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
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 cour
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,
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 pat
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*
On Mon, Jan 02, 2012 at 09:28:39AM +0100, Romain Francoise wrote:
> Axel Beckert 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 u
Axel Beckert 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 in order to re
On Mon, 2 Jan 2012 04:13:44 +0100
Axel Beckert 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, ye
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
> >
Axel Beckert 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 would be better
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, e
On Jan 02, 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
As long as the needed patch is simple. But if it were, this w
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" t
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 oth
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 GNU
43 matches
Mail list logo
