procps 2.0.13 with NPTL enhancements
A message that is not in the archive (sent off-list or not yet received): 1054270854.22088.617.camel@cube
Quoted 22 lines · Albert Cahalan
Robert Love writes:
Quoted 9 lines · Adrian Bunk
Quoted 3 lines
Well, since I read Albert Cahalan's comment in
Debian bug #172735 [1] I understand the people
maintaining a different branch...Exactly.
That bug is fixed in the official tree, fyi.
A segfault, as you said, is always a bug.
An error message is displayed.You asked for it...
Nice cheapshot there. So, if I remove some critical kernel interfaces from your system, nothing should crash? How about I take out a few choice system calls or a chunk of libc?
(note: the "bug" is not exploitable)
Quoted 7 lines
Face it. For nearly a decade, /proc has been a critical kernel interface. This isn't 1991. (embedded systems excepted; they don't use procps)
That said, I may do something about the issue simply to please users with messed-up systems.
...
Disabling the proc filesystem is simple by unchecking one item in the kernel config menu and different from taking out "a chunk of libc" it's more or less supported.
I don't say #172735 is exploitable. An error message "Error: /proc isn't mounted" tells you what is wrong, a segmentation fault tells you _nothing_.
I've seen at several occasions that several man days were lost trying to find problems in other programs that caused segmentation faults. In the end things like diff'ing strace files give you important hints after hours of clueless searching. Error messages instead of segmentation faults would have prevented several fruitless hours in my live.
After reading the last sentence you might perhaps understand my opinion about the quality of a software whose maintainer says about a segmentation fault "Crashing is kind of a good thing even. ... In error checking, there is a certain balance to achieve." .
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 3 lines · Adrian Bunk
Disabling the proc filesystem is simple by unchecking one item in the kernel config menu and different from taking out "a chunk of libc" it's more or less supported.
It's worse: if a system is brought up for reduced operation, e.g. with init=/bin/sh for repair work, it is not uncommon for /proc to be absent.
Since it is not immediately obvious for a user whether a given program depends on /proc or not, just crashing in such a situation is clearly a case poor user interface design.
- Werner
Signature · 3 lines
_________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [email protected] / /_http://www.almesberger.net/____________________________________________/
Quoted 17 lines · Albert Cahalan
Quoted 6 lines · Adrian Bunk
Once that bug is fixed, he will probably find that the inability to read files in /proc also causes a crash. Such is the problem with this duplicated effort. It sucks.
I could tell you about some inputs that make your programs crash... Nah. Find them yourself. I wait for your screams. >:-)
You finally fixed a SEGV that I fixed well over a year ago. Congradulations. You have others to fix, and a minor (?) security issue as well. Have fun.
Quoted 4 lines
Oooh... I think you have an exploitable buffer overflow as well. Anybody running his procps as an i386 binary on IA-64? [...]
Mine is longer, I have more hair, less tummy...
please, stop your childish nonsense.
A fork has sense if latter the code are going to merge (like gcc/egcs, xfree/xwin, linux/ac/mm/aa/osdl...) or the proyect are going to take another goal.
But to have two proyects, same code(more or less), same goal. And it's worse for to be a base crical package. Its's waste time/resources and to do a little different every distribution.
-thank you-
regards,
Signature · 1 line
Software is like sex, it's better when it's bug free.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Xose Vazquez Perez
Mine is longer, I have more hair, less tummy...
please, stop your childish nonsense.
Quoted 8 lines
A fork has sense if latter the code are going to merge (like gcc/egcs, xfree/xwin, linux/ac/mm/aa/osdl...) or the proyect are going to take another goal.
But to have two proyects, same code(more or less), same goal. And it's worse for to be a base crical package. Its's waste time/resources and to do a little different every distribution.
You've made your point, here and elsewhere. Both parties involved disagree. I suggest you spend your efforts elsewhere:
OpenBSD should merge with NetBSD. XEmacs should merge with GNU Emacs. CinePaint should merge with The Gimp. Windows should merge with OS/2.
After you solve those problems, you can tackle projects that aren't truly forks. For example, we only need one editor.