Hi,
how about releasing 2.4.21 with the ptrace()-fix applied immediately
like it has been done with 2.2.25?
I think it's a serious bug and therefore it's time for a security-update.
If you think of ISC bind, PHP, sendmail or other software a new release
follows right after the availability of the patch. I'd like Linux
(and glibc as well) to do the same. You cannot call 2.4.20 a stable kernel
with such a bug, so as a leader of the 2.4.x-series you cannot call the
whole branch "stable".
World needs to update, best way to enforce is by a new release.
--
mail: [email protected] http://adi.thur.de PGP: v2-key via keyserver
Das letzte Schoene, das in C geschrieben wurde, war Schuberts 9. Sinfonie.
On 3487 September 1993, Adrian Knoth wrote:
> how about releasing 2.4.21 with the ptrace()-fix applied immediately
> like it has been done with 2.2.25?
>
> I think it's a serious bug and therefore it's time for a security-update.
I think the best way is to release a 2.4.21 kernel with only the
most important fixes (e.g. ptrace, ext3) and no new features. All
new featues which need more testing and are now in 2.4.21-pre could
then go to 2.4.22-pre for more testing (as Alan did with
2.2.25-pre1). This would be a way to react to important bugs very
fast without a lack of enough testing which is just impossible with
the current release scheme. It's just too dangerous to call 2.4.20
"stable" and wait another few month for 2.4.21.
Sebastian
On Thu, Mar 20, 2003 at 09:21:01PM +0100, Sebastian D.B. Krause wrote:
> On 3487 September 1993, Adrian Knoth wrote:
> > how about releasing 2.4.21 with the ptrace()-fix applied immediately
> > like it has been done with 2.2.25?
> >
> > I think it's a serious bug and therefore it's time for a security-update.
>
> I think the best way is to release a 2.4.21 kernel with only the
> most important fixes (e.g. ptrace, ext3) and no new features. All
> new featues which need more testing and are now in 2.4.21-pre could
> then go to 2.4.22-pre for more testing (as Alan did with
Something vaguely like this has been suggested, which I think is a good
idea:
For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
the 2.4.21-pre cycle, that would be less productive than just patching
2.4.20 and rolling a separate release off of that.
Jeff
[email protected] (Sebastian D.B. Krause) writes:
> I think the best way is to release a 2.4.21 kernel with only the
> most important fixes (e.g. ptrace, ext3) and no new features.
You can do this on your own. So what?
Releasing an official 2.4.21 with some fixes (and no new features) is
just a PR issue. I've already seen people comparing the alleged IIS
bug (or this new IE hole) and the ptrace() bug...
On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
> the 2.4.21-pre cycle, that would be less productive than just patching
> 2.4.20 and rolling a separate release off of that.
I think the naming is illogical. If there's a bugfix-only release
it whould have normal incremental numbers. So if marcelo want's
it he should clone a tree of at 2.4.20, apply the essential patches
and bump the version number in the normal 2.4 tree to 2.4.22-pre1
On Thu, Mar 20, 2003 at 08:42:18PM +0000, Christoph Hellwig wrote:
> On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
> > the 2.4.21-pre cycle, that would be less productive than just patching
> > 2.4.20 and rolling a separate release off of that.
>
> I think the naming is illogical. If there's a bugfix-only release
Many, many companies seem to find it logical. If you want to squeeze
a version in between "1" and "2".
Further, other kernel hackers suggested the 2.4.20.N sequence,
I simply agreed with it. So it's not only me who thinks this way :)
> it whould have normal incremental numbers. So if marcelo want's
> it he should clone a tree of at 2.4.20, apply the essential patches
> and bump the version number in the normal 2.4 tree to 2.4.22-pre1
Human nature says that will drag out the -pre tree ad infinitum.
Suppose a 2.4.21 is released today, with 2.4.20 + bug fixes. Now,
tomorrow, another "critical bug" comes out, and then the -pre tree
becomes 2.4.23-pre. Add another critical bug, and I hope you see
the continual delay of -pre happens here...
The basic logic is "do not disrupt current plans. Do something
_in addition to_ current plans."
Jeff
On Thu, Mar 20, 2003 at 09:43:01PM +0100, Florian Weimer wrote:
> Releasing an official 2.4.21 with some fixes (and no new features) is
> just a PR issue. I've already seen people comparing the alleged IIS
> bug (or this new IE hole) and the ptrace() bug...
Comparing, how? There is no comparison.
The ptrace bug is only one of several local root holes. IIS would imply
a remote vulnerability, something _far_ more serious.
This specific ptrace hole is closed, yay. Now what about the other
10,001 that still exist? People are blowing this ptrace bug WAY
out of proportion. The only reason why it demands a modicum of
vendor responsibility is that a-holes are making easy-to-use exploits
available for the script kiddies.
In my more cynical moods, I wish bugtraq'ers would start posting
exploits to all the races in GNU coreutils (cp/mv/rm/...). Assuming
such actions would (finally) lead to bug fixes.... maybe then I will
start taking local root holes a bit more seriously. I will no more
than hint about this in public, but will respond privately with details
(if I know you).
Jeff
hopefully we won't have a steady stream of critical bugs. if we do we need
to stop new development and find out where we are going wrong.
after all this isn't microsoft.
one advantage of useing a good version control system is that it should be
very easy to make a minor update to 2.4.20 to produce 2.4.21 without it
being a major disruption to things and then continue with the existing
development. from what I understand about bk it should make it even
easier.
I don't like going to 4 part version numbers. if this was a marketing
driven company that had promised features in 2.4.21 and they aren't ready
but a new version is needed then we would have a reason to do a 2.4.20.1
so that we don't have to deal with broken promises, but sine we aren't in
that situation I don't see why the 2.4.20.N is needed.
Every other time there has been a critical bug it was fixed in the next
normal release number (or if it's critical enough it was handled by
rushing a version with just that fix like happened with 2.2)
David Lang
On Thu, 20 Mar 2003, Jeff Garzik wrote:
> Date: Thu, 20 Mar 2003 15:53:38 -0500
> From: Jeff Garzik <[email protected]>
> To: Christoph Hellwig <[email protected]>, [email protected],
> [email protected]
> Subject: Re: Release of 2.4.21
>
> On Thu, Mar 20, 2003 at 08:42:18PM +0000, Christoph Hellwig wrote:
> > On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> > > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
> > > the 2.4.21-pre cycle, that would be less productive than just patching
> > > 2.4.20 and rolling a separate release off of that.
> >
> > I think the naming is illogical. If there's a bugfix-only release
>
> Many, many companies seem to find it logical. If you want to squeeze
> a version in between "1" and "2".
>
> Further, other kernel hackers suggested the 2.4.20.N sequence,
> I simply agreed with it. So it's not only me who thinks this way :)
>
>
> > it whould have normal incremental numbers. So if marcelo want's
> > it he should clone a tree of at 2.4.20, apply the essential patches
> > and bump the version number in the normal 2.4 tree to 2.4.22-pre1
>
> Human nature says that will drag out the -pre tree ad infinitum.
> Suppose a 2.4.21 is released today, with 2.4.20 + bug fixes. Now,
> tomorrow, another "critical bug" comes out, and then the -pre tree
> becomes 2.4.23-pre. Add another critical bug, and I hope you see
> the continual delay of -pre happens here...
>
> The basic logic is "do not disrupt current plans. Do something
> _in addition to_ current plans."
>
> Jeff
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
What would concern me about releasing 2.4.21 with just this bugfix is the
reports I've seen of it breaking other things (kill, etc). Have these
issues been addressed?
Followup to: <[email protected]>
By author: Jeff Garzik <[email protected]>
In newsgroup: linux.dev.kernel
>
> The ptrace bug is only one of several local root holes. IIS would imply
> a remote vulnerability, something _far_ more serious.
>
Don't forget: local root exploit + remote non-root exploit -> remote
root exploit.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Jeff Garzik <[email protected]> writes:
> On Thu, Mar 20, 2003 at 09:43:01PM +0100, Florian Weimer wrote:
>> Releasing an official 2.4.21 with some fixes (and no new features) is
>> just a PR issue. I've already seen people comparing the alleged IIS
>> bug (or this new IE hole) and the ptrace() bug...
>
> Comparing, how? There is no comparison.
You know it, I know it, our readers know it. But the press puts them
on the same level nevertheless.
> This specific ptrace hole is closed, yay. Now what about the other
> 10,001 that still exist? People are blowing this ptrace bug WAY
> out of proportion.
I agree completely. Local security on traditional UNIX-like systems
is *so* poor that this bug doesn't really matter. No admin of a sane
mind lets untrusted users access important systems.
> The only reason why it demands a modicum of vendor responsibility is
> that a-holes are making easy-to-use exploits available for the
> script kiddies.
No, you miss a point. These exploits are important to keep you kernel
developers honest. Otherwise, you would have fixed this quitely, like
a couple of other bugs. Admins would assume that kernels offered a
decent level of local security, which can lead to very questionable
decisions.
On 3487 September 1993, Jeff Garzik wrote:
> The ptrace bug is only one of several local root holes. IIS would imply
> a remote vulnerability, something _far_ more serious.
>
> This specific ptrace hole is closed, yay. Now what about the other
> 10,001 that still exist? People are blowing this ptrace bug WAY
> out of proportion.
That may be true, but inspite of that there is another important and
dangerous bug in 2.4.20 (the ext3 thing) that IMHO is enough reason
to release a new kernel.
On Thu, 20 Mar 2003 16:03:05 -0500
Jeff Garzik <[email protected]> wrote:
> 10,001 that still exist? People are blowing this ptrace bug WAY
> out of proportion. The only reason why it demands a modicum of
Indeed, everybody i know is recompiling and rebooting; although
they're just plain linux where they're the one users and
remote login isn't allowed.....
Christoph Hellwig <[email protected]> wrote:
>
> On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
> > the 2.4.21-pre cycle, that would be less productive than just patching
> > 2.4.20 and rolling a separate release off of that.
>
> I think the naming is illogical. If there's a bugfix-only release
> it whould have normal incremental numbers. So if marcelo want's
> it he should clone a tree of at 2.4.20, apply the essential patches
> and bump the version number in the normal 2.4 tree to 2.4.22-pre1
No point in making things too complex. 2.4.20-post1 is something people can
easily understand.
I needed that for the ext3 problems which popped up shortly after 2.4.20 was
released - I was reduced to asking people to download fixes from my web page.
And having a -post stream may allow us to be a bit more adventurous in the
-pre stream.
On Thu, 2003-03-20 at 21:17, Dow, Benjamin wrote:
> What would concern me about releasing 2.4.21 with just this bugfix is the
> reports I've seen of it breaking other things (kill, etc). Have these
> issues been addressed?
No one has sent me any patches, any analysis of the changes identifying
problems or alternative fixes.
Alan
On Thu, 2003-03-20 at 19:56, Adrian Knoth wrote:
> (and glibc as well) to do the same. You cannot call 2.4.20 a stable kernel
> with such a bug, so as a leader of the 2.4.x-series you cannot call the
> whole branch "stable".
>
> World needs to update, best way to enforce is by a new release.
The vendors have released updated kernels. Whats the problem ?
> > > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
> > > the 2.4.21-pre cycle, that would be less productive than just patching
> > > 2.4.20 and rolling a separate release off of that.
> >
> > I think the naming is illogical. If there's a bugfix-only release
> > it whould have normal incremental numbers. So if marcelo want's
> > it he should clone a tree of at 2.4.20, apply the essential patches
> > and bump the version number in the normal 2.4 tree to 2.4.22-pre1
>
> No point in making things too complex. 2.4.20-post1 is something people can
> easily understand.
>
> I needed that for the ext3 problems which popped up shortly after 2.4.20 was
> released - I was reduced to asking people to download fixes from my web page.
>
> And having a -post stream may allow us to be a bit more adventurous in the
> -pre stream.
Why can't we just make all releases smaller and more frequent?
Why do we need 2.4.x-pre at all, anyway - why can't we just test
things in the -[a-z][a-z] trees, and _start_ with -rc1?
Why can't we just do bugfixes for 2.4, and speed up 2.5 development?
John.
if official kernels were being released more rapidly then they are it
wouldn't be much of a problem (I can wait a week or two for this with no
problem) but it's currently several months between releases, and since
there are so many changes there is the potential that a new kernel could
be worse then what you are running.
yes I could download a patch and fix the kernel that way, but while I
understand how simple that is I can already hear the crys from management
about haphazardly patching things that then get put into production.
and as for the vendor kernels, I don't use them becouse they all make a
ton of changes that I don't want to deal with.
the stable kernel releases are a vendor for this situation and this
'vendor' has chosen to consider this bug not critical (along with a couple
others) which is a decision being questioned by folks.
David Lang
On 21 Mar 2003, Alan Cox wrote:
> Date: 21 Mar 2003 01:01:34 +0000
> From: Alan Cox <[email protected]>
> To: Adrian Knoth <[email protected]>
> Cc: Linux Kernel Mailing List <[email protected]>
> Subject: Re: Release of 2.4.21
>
> On Thu, 2003-03-20 at 19:56, Adrian Knoth wrote:
> > (and glibc as well) to do the same. You cannot call 2.4.20 a stable kernel
> > with such a bug, so as a leader of the 2.4.x-series you cannot call the
> > whole branch "stable".
> >
> > World needs to update, best way to enforce is by a new release.
>
> The vendors have released updated kernels. Whats the problem ?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
* Jeff Garzik ([email protected]) wrote:
>
> The ptrace bug is only one of several local root holes. IIS would imply
> a remote vulnerability, something _far_ more serious.
>
> This specific ptrace hole is closed, yay. Now what about the other
> 10,001 that still exist? People are blowing this ptrace bug WAY
> out of proportion. The only reason why it demands a modicum of
> vendor responsibility is that a-holes are making easy-to-use exploits
> available for the script kiddies.
I know it's already been said, but IMHO it needs to be underscored. Local
root holes are just a simple non-root remote exploit away from being
remotely exploitable root holes. Both are often considered
insignificant, and that is scary! As far as fileutils...couldn't agree
more ;-) But that doesn't make a locally exploitable root hole in the
kernel any less significant.
cheers,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
John Bradford wrote:
>>>>For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
>>>>the 2.4.21-pre cycle, that would be less productive than just patching
>>>>2.4.20 and rolling a separate release off of that.
>>>>
>>>>
>>>I think the naming is illogical. If there's a bugfix-only release
>>>it whould have normal incremental numbers. So if marcelo want's
>>>it he should clone a tree of at 2.4.20, apply the essential patches
>>>and bump the version number in the normal 2.4 tree to 2.4.22-pre1
>>>
>>>
>>No point in making things too complex. 2.4.20-post1 is something people can
>>easily understand.
>>
>>I needed that for the ext3 problems which popped up shortly after 2.4.20 was
>>released - I was reduced to asking people to download fixes from my web page.
>>
>>And having a -post stream may allow us to be a bit more adventurous in the
>>-pre stream.
>>
>>
>
>Why can't we just make all releases smaller and more frequent?
>
>Why do we need 2.4.x-pre at all, anyway - why can't we just test
>things in the -[a-z][a-z] trees, and _start_ with -rc1?
>
>Why can't we just do bugfixes for 2.4, and speed up 2.5 development?
>
>
>
That would imply some changes could take place in a short cycle. This
is not true for things like major ide subsystem updates.
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory <[email protected]>
John Bradford <[email protected]> wrote:
>>Why can't we just make all releases smaller and more frequent?
>
>Why do we need 2.4.x-pre at all, anyway - why can't we just test
>things in the -[a-z][a-z] trees, and _start_ with -rc1?
>
>Why can't we just do bugfixes for 2.4, and speed up 2.5 development?
Because 2.4 is used on (real) production systems - even my desktop PC
on my workplace is considered a production system - which (at least)
should run and therefore trying 2.5 is not an option (and no, no way).
And then it takes 1.5 years for the next stable kernel release which
implies that quite new hardware (without an existing driver) cannot be
used for any production-like system.
IOW you would just loose a lot real use and testing of backported
stuff and new hardware drivers.
And no, I don't think that someone wants that.
Bernd
--
Bernd Petrovitsch Email : [email protected]
g.a.m.s gmbh Fax : +43 1 205255-900
Prinz-Eugen-Stra?e 8 A-1040 Vienna/Austria/Europe
LUGA : http://www.luga.at
> >>Why can't we just make all releases smaller and more frequent?
> >
> >Why do we need 2.4.x-pre at all, anyway - why can't we just test
> >things in the -[a-z][a-z] trees, and _start_ with -rc1?
> >
> >Why can't we just do bugfixes for 2.4, and speed up 2.5 development?
>
> Because 2.4 is used on (real) production systems - even my desktop PC
> on my workplace is considered a production system - which (at least)
> should run and therefore trying 2.5 is not an option (and no, no way).
> And then it takes 1.5 years for the next stable kernel release which
> implies that quite new hardware (without an existing driver) cannot be
> used for any production-like system.
I would include support for new chipsets in with bugfixes.
> IOW you would just loose a lot real use and testing of backported
> stuff and new hardware drivers.
If nobody tests 2.5.x on a specific piece of hardware, 2.6.0 will be
released without being tested on that piece of hardware.
Incrementing the version number from 2.5.$bignum to 2.6.0 does _not_
magically fix all the bugs in it.
> And no, I don't think that someone wants that.
Production systems should be backed up. No question about that.
Unless the system has to run 24/7, which a desktop machine usually
doesn't have to, I don't see why testing 2.5 on it isn't a
possibility.
John.
> >>>>For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
> >>>>the 2.4.21-pre cycle, that would be less productive than just patching
> >>>>2.4.20 and rolling a separate release off of that.
> >>>>
> >>>>
> >>>I think the naming is illogical. If there's a bugfix-only release
> >>>it whould have normal incremental numbers. So if marcelo want's
> >>>it he should clone a tree of at 2.4.20, apply the essential patches
> >>>and bump the version number in the normal 2.4 tree to 2.4.22-pre1
> >>>
> >>>
> >>No point in making things too complex. 2.4.20-post1 is something people can
> >>easily understand.
> >>
> >>I needed that for the ext3 problems which popped up shortly after 2.4.20 was
> >>released - I was reduced to asking people to download fixes from my web page.
> >>
> >>And having a -post stream may allow us to be a bit more adventurous in the
> >>-pre stream.
> >>
> >>
> >
> >Why can't we just make all releases smaller and more frequent?
> >
> >Why do we need 2.4.x-pre at all, anyway - why can't we just test
> >things in the -[a-z][a-z] trees, and _start_ with -rc1?
> >
> >Why can't we just do bugfixes for 2.4, and speed up 2.5 development?
> >
> >
> >
>
> That would imply some changes could take place in a short cycle. This
> is not true for things like major ide subsystem updates.
We should not have major updates like that as a regular occurance in
the stable kernel series. If they are necessary, we could break with
the small, frequent updates, and go back to what we have now.
Why can't we basically have two modes of working:
* When nothing major is being re-written:
Small, frequent updates. -pre and -rc version numbering used to
indicate kernels which haven't had much testing. Larger updates
existing in -[a-z][a-z] trees.
* When an update to a core subsystem is in progress
Larger, less frequent updates. -pre and -rc versions getting more
testing, and -[a-z][a-z] trees for very experimental code.
I know there are frequently suggestions about how to organise kernel
development, and they are usually ignored, because we generally don't
like to work however we want to, but this suggestion is just common
sense. When nothing much is going on, release smaller changes to get
a lot of testing of the same codebase. When major work is going on,
separate out the minor updates to give people flexibility in testing.
John.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 20 March 2003 23:08, Sebastian D.B. Krause wrote:
>
> That may be true, but inspite of that there is another important and
> dangerous bug in 2.4.20 (the ext3 thing) that IMHO is enough reason
> to release a new kernel.
Btw, what ext3 patches are these exactly?
- From subdir 00-merged/ at
http://people.redhat.com/sct/patches/ext3-2.4/dev-20030314/
More/other patches? There seem to be some (all?) of those mentioned in the
.21-pre changelog but can someone please cleary state what ext3 patches
should be applied?
- --
Oliver Feiler <kiza@(kcore.de|lionking.org|gmx(pro).net)>
http://kiza.kcore.de/ <-- homepage
PGP-key --> /pgpkey.shtml
http://kiza.kcore.de/journal/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+evI+OpifZVYdT9IRAuksAJ45QBi9gPXrKRHrPGgDlRmanlSmNgCguKFL
v5PrWhB/49KKgeE/kvwxF1A=
=A3QG
-----END PGP SIGNATURE-----
Am Fre, 2003-03-21 um 10.23 schrieb John Bradford:
> Unless the system has to run 24/7, which a desktop machine usually
> doesn't have to, I don't see why testing 2.5 on it isn't a
> possibility.
Because desktop systems usually don't feature the notion of a testbed,
read an environment in which dangerous changes can be tested without
severe loss of important data.
I would never ever boot a 2.5.x kernel on my notebook or on any other
machines without preparing a different harddrive for instance, YMMV
though.
--
Servus,
Daniel
> > Unless the system has to run 24/7, which a desktop machine usually
> > doesn't have to, I don't see why testing 2.5 on it isn't a
> > possibility.
>
> Because desktop systems usually don't feature the notion of a testbed,
> read an environment in which dangerous changes can be tested without
> severe loss of important data.
So why did you trim the part of my quote that said that production
systems should always be backed up anyway?
> I would never ever boot a 2.5.x kernel on my notebook or on any other=20
> machines without preparing a different harddrive for instance, YMMV
> though.
It's not exactly much work to put a different disk in a machine. With
a notebook, it might be 30-45 minutes work dismantling it, but on a
typical desktop, about 2 minutes, and on a rackmount server, probably
60 seconds.
John.
Am Sam, 2003-03-22 um 09.27 schrieb John Bradford:
> So why did you trim the part of my quote that said that production
> systems should always be backed up anyway?
You consider normal desktop systems "production system"? Interesting...
The best on can hope for a desktop system is a regular becakup of
important work files to CD-R; we're more talking about a sector-wise
harddisk backup here which is not even common for server systems (no,
I'm not talking about RAID here) let alone Joe users system.
For instance I do have a RAID and a regular rsync backup on my
production system here. That's still not enough for trying development
kernels on real data which might fry the filesystem because it'd be
fried on the mirrored harddrives at the same time and the rsynced copy
is not enough to fully recover the system.
> It's not exactly much work to put a different disk in a machine.
Yeah, though not something Joe user could do. And honestly this is not
something someone would do "just for fun", because it's still a lot of
trouble for a minor intent.
> With a notebook, it might be 30-45 minutes work dismantling it,
You certainly must be kidding. Dismantling my PowerBook is hardly
possible at all without killing it and the harddrive is quite hard to
replace. This is more like a 2h work and something I'd rather do once
in its lifetime for the sake of a bigger harddrive instead of trying
a development kernel.
> but on a typical desktop, about 2 minutes, and on a rackmount server, probably
> 60 seconds.
Right. Let's see. It took me about 20 minutes to swap the CPU in this
"desktop" machine here, 15 minutes of that were used to dismantle the
system, pull the mounted motherboard (with all PCI cards in the slots,
my case luckily allows for that) and reassemble those parts. This action
is necessary to get to the right hand side screws which fasten the
harddrive.
It's not even realistic to assume that simply opening the case, and
reconnecting a loosely hanging around harddrive will just take 2
minutes.
--
Servus,
Daniel
Hi!
> This specific ptrace hole is closed, yay. Now what about the other
> 10,001 that still exist? People are blowing this ptrace bug WAY
> out of proportion. The only reason why it demands a modicum of
> vendor responsibility is that a-holes are making easy-to-use exploits
> available for the script kiddies.
>
> In my more cynical moods, I wish bugtraq'ers would start posting
> exploits to all the races in GNU coreutils (cp/mv/rm/...). Assuming
> such actions would (finally) lead to bug fixes.... maybe then I will
> start taking local root holes a bit more seriously. I will no more
> than hint about this in public, but will respond privately with details
> (if I know you).
Can you give me the details? I can
imagine holes like "if I can force root
to rm -rf /tmp/my-dir while my scripts
are running, I can rm whatever I want"
and probably could force root to cp
files he did not want to copy, but that
would require a *lot* of social ingeneering...
Unlike ptrace which seems to be "gimme root, now!"
case.
Pavel
(I left l-k in cc, you may want to strip it)
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...