Jim Bryant [EMAIL PROTECTED] writes:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024);
for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n, argv[1], i);
system((const char *)buf);} return(0);}
Subject should be how to take
Patient: Doctor, it hurts when I do this!
Doctor: Don't do that...
On Feb 18, 2008 1:23 PM, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Jim Bryant [EMAIL PROTECTED] writes:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024);
On Mon, Feb 18, 2008 at 02:53:59PM +0100, Dag-Erling Sm??rgrav wrote:
Two bugs:
[skip]
That's all very funny, but what about a panic?
It it true that it's possible for non-root to bring a file system
to not-mountable state?
Eugene Grosbein
___
Dag-Erling Smørgrav wrote:
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Purely in the interest of showing off, here is my version. It is 81
bytes shorter than yours, it is valid C99 with POSIX extensions (yours
is not), and it produces 11,450 files in about 0.2% of the time yours
takes to
Dag-Erling: you win! Your's longer a couple of inches :)
Sorry, my hands runs in front of the loco...
Hope there are not much of *such* styled preprocessor code in FreeBSD?
It should be a plain suicide to fix a bug in it.
2008/2/18, Dag-Erling Smørgrav [EMAIL PROTECTED]:
Dag-Erling Smørgrav
Time for the idiot(proof) function call.
Got brakes?
==
25hrs or one season with one pad set is possible. Save money and pit
time, compromise nothing. Ask how.
TXT or Tone: [EMAIL PROTECTED]
http://www.speedtoys.com
On Feb 18, 2008, at 8:27 AM, Kurt Buff [EMAIL PROTECTED] wrote:
Patient: Doctor, it hurts when I do this!
Doctor: Don't do that...
Did you actually bother to read his report?
While his example is used /, if the report is correct then you
just need to replace / with the path of any file system mount
point that is world writable like say /tmp.
Do you
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Purely in the interest of showing off, here is my version. It is 81
bytes shorter than yours, it is valid C99 with POSIX extensions (yours
is not), and it produces 11,450 files in about 0.2% of the time yours
takes to produce 10,000.
#include
On Sun, 17 Feb 2008, Jim Bryant wrote:
FYI: The system assigned kern/120781 to this bug report.
IMHO, a security advisory should be issued ASAP.
Thanks for the report, I'm sure your widely distributed e-mail will get
someone looking at it quickly. In the future if you run into an issue
Hi,
I would agree with Mark and Jim, this is a serious issue for enterprise
servers. Yet another example where I would have wanted to see a more
supportive response from the FreeBSD project members, like Robert Watson
just did. This would benefit keeping a good relation with the business
users.
Adrian Penisoara wrote:
Hi,
I would agree with Mark and Jim, this is a serious issue for enterprise
servers. Yet another example where I would have wanted to see a more
supportive response from the FreeBSD project members, like Robert Watson
just did. This would benefit keeping a good
Since this was released to a public mailing list, I can only assume some
less than nice user will attempt this.
The only top level file system I have that can be written to by normal users
is /tmp
Should clear_tmp_enable=YES in /etc/rc.conf prevent this from causing
harm?
Dan
On Feb 17, 2008
Daniel Corrigan wrote:
Since this was released to a public mailing list, I can only assume some
less than nice user will attempt this.
The only top level file system I have that can be written to by normal users
is /tmp
Should clear_tmp_enable=YES in /etc/rc.conf prevent this from causing
harm?
On Mon, 18 Feb 2008, Daniel Corrigan wrote:
Since this was released to a public mailing list, I can only assume some
less than nice user will attempt this. The only top level file system I have
that can be written to by normal users is /tmp
Should clear_tmp_enable=YES in /etc/rc.conf prevent
On Mon, 18 Feb 2008, Robert Watson wrote:
Hopefully this bug will get resolved shortly, and then we can evaluate if an
errata notice is necessary.
FYI, I have been unable, thus far, to reproduce it with 150,000 entries in the
root of a test file system on an 8.x kernel. I'm not set up to
On Mon, Feb 18, 2008 at 09:14:30AM -0600, Daniel Corrigan wrote:
Since this was released to a public mailing list, I can only assume
some less than nice user will attempt this. The only top level file
system I have that can be written to by normal users is /tmp
Should clear_tmp_enable=YES in
Eugene Grosbein wrote:
On Mon, Feb 18, 2008 at 02:53:59PM +0100, Dag-Erling Sm??rgrav wrote:
Two bugs:
[skip]
That's all very funny, but what about a panic?
It it true that it's possible for non-root to bring a file system
to not-mountable state?
The issue appears to be more subtle than
[CC list trimmed]
On Sun, Feb 17, 2008 at 10:24:08PM -0600, Jim Bryant wrote:
How to repeat the problem:
Compile and run the following as instructed:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024);
for(i = 0; i 1; i++) {
On Mon, 2008-02-18 at 17:21 +, Robert Watson wrote:
On Mon, 18 Feb 2008, Robert Watson wrote:
Hopefully this bug will get resolved shortly, and then we can evaluate if
an
errata notice is necessary.
FYI, I have been unable, thus far, to reproduce it with 150,000 entries in
the
Jim's original report seemed to indicate that the filesystem paniced
on mount even after repeated fsck's.
That implies that Jim has a filesystem image that panics on mount.
Maybe Jim can make that image available and a few people can see if
downloading and mounting it
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause
a panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release You Are Using:
6.3-STABLE
Environment (output of uname -a on the problem machine):
FreeBSD wahoo.sd67dfl.org 6.3-STABLE
FYI: The system assigned kern/120781 to this bug report.
IMHO, a security advisory should be issued ASAP.
Jim Bryant wrote:
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause
a panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release
22 matches
Mail list logo