Re: [PATCH] adding two new options to 'cp'
On Tue, 01 Aug 2006, Ivan Voras wrote: Peter Jeremy wrote: Note that it isn's possible to accurately distinguish between a block of NULs and a hole in the file through the filesystem. The only way to accurately copy a sparse file is with dump/restore. Hence the need for an explicit switch. A switch doesn't help. A sparse file can contain both holes and blocks of NULs. You could, I suppose, do something like -s 100, which would seek past any block of 100 NULs. -- David Taylor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sat, 08 Apr 2006, Mike Meyer wrote: In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. Because Unix has always made the hardware details available to administrators. Times have changed so that users now need to do things that used to be restricted to administrators. This historical behavior is a *good* thing. If all devices of type foo are just named foo and assigned numbers by the system, then I have no control over the names. If I don't care which is which, this isn't a problem. If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. That doesn't quite work, though. Unless you require everyone wanting to distinguish between LAN and WAN interfaces uses different types of hardware for each card, they'll still end up with xl0 and xl1 (or whatever), which is in no way better than eth0 and eth1, except that it means you have the option of looking up what on earth xl actually means to get a vague description of what type of hardware it is, rather than checking the dmesg for xlX or ethX. -- David Taylor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID5 on athlon64 machines
On Sun, 12 Feb 2006, [EMAIL PROTECTED] wrote: [missing attribution] You compute max data rates by considering the most optimistic scenario, which is large sequetial writes. For *this* situation write rate will be higher than a single disk's. How can the RAID5 write rate be higher for the whole array if not only it needs to write the data to all if its drives, but also compute and write a parity block? Easy, you can write simultaneously to more than one drive, assuming the drive was the bottleneck in the first place. -- David Taylor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: Question regarding shell user creation at login time
On Tue, 30 Mar 2004, ghos wrote: You wrote 29 mar 2004, 8:05:55 +0500: Hi, I traced sshd using ktrace and it says: .. 10198 new CALL setuid(0) 10198 new RET setuid -1 errno 1 Operation not permitted 10198 new CALL execve(0x80485d0,0xbfbfed8c,0xbfbfed94) 10198 new NAMI /home/new/new.pl 10198 new RET execve -1 errno 13 Permission denied 10198 new CALL exit(0x) . [snip] Directory: public# ls -la ~new total 46 drwxr-xr-x 2 root wheel512 Mar 29 09:10 . drwxr-xr-x 8 root wheel512 Mar 25 15:28 .. -r--r- 1 root new 767 Mar 24 17:43 .cshrc -r--r- 1 root new 248 Mar 26 12:32 .login -r--r- 1 root new 158 Mar 24 17:43 .login_conf -r--r- 1 root new 373 Mar 24 17:43 .mail_aliases -r--r- 1 root new 331 Mar 24 17:43 .mailrc -r--r- 1 root new 797 Mar 24 17:43 .profile -r--r- 1 root new 276 Mar 24 17:43 .rhosts -r--r- 1 root new 975 Mar 24 17:43 .shrc -rwsr-x--- 1 root new 4651 Mar 26 08:47 new -- 1 root wheel 94 Mar 26 08:47 new.c -r-x-- 1 root wheel 15430 Mar 25 15:16 new.pl -rw-r--r-- 1 root wheel 52 Mar 25 16:52 new.sh Can somebody tell me the reason why it is failed? Thanks in advance, Ganbold You are not root! You are 'new' in 'new'-group. Try this: # chmod g+x ~new/new.pl But in theory he should be root, since ~new/new is suid root. Since setuid(0) is failing, you are presumably correct that he is not, though. In any case, ~new/new.pl is owned by group wheel, so g+x won't help, without also changing the group to 'new'. Also, I think for scripts at least, read permission is required in addition to execute permission. (Since you're executing the interpreter, which then reads the script) I'd suggest checking get[e]uid() in ~new/new, and figuring out what it's running as (presumably 'new' group 'new'), and why it's not running as 'root', which it should be. If you give 'new' a real shell and log in, then execute ~new/new, what uid does it run as? If that works, I guess it's something ssh is doing (or a bug/feature in the kernel tickled by ssh) As for whether it's a good idea to be trying to set up an automated free shell server without being able to make the above work with your eyes closed... well... Assuming it's just a spare box with some spare network bandwidth to it, and no important data or access to important hosts on the same network, you probably don't care what happens to it. Just remember that _you_ will be held responsible if people start sending worms/spam/abuse from your host, or start installing irc bots (which are can be the target of large denial of service attacks). Personally, trying to keep a shell service running for paying (some of them at least, the rest were using stolen credit cards) customers was enough of a nightmare to encourage me never to give anyone I wouldn't explicitly trust with root on my box any access at all. -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: First prg with sysctl
On Sat, 13 Oct 2001, Paolo Pisati wrote:
Someone can tell me why this piece of code doesn't work?
#includestdio.h
#include sys/types.h
#include sys/socket.h
#include sys/sysctl.h
#include sys/time.h
#include net/if.h
#include net/if_mib.h
int main(void) {
int mib[5], *count;
Here you define 'count' as an uninitialised pointer to an integer.
mib[0]=CTL_NET;
mib[1]=PF_LINK;
mib[2]=NETLINK_GENERIC;
mib[3]=IFMIB_SYSTEM;
mib[4]=IFMIB_IFCOUNT;
sysctl(mib, 5, count, sizeof(int),(void *)NULL, NULL);
Here, in arg three, you pass the value of 'count' as the address to store
the count in, so you're storing it in some random address, probably
resulting in -1 being returned with errno=EFAULT.
In arg 4, you pass 'sizeof(int)' (probably 4) as the address of a size_t
containing the length of the value, also probably resulting in EFAULT.
In arg 5, casting NULL to (void *) is somewhat redundant.
In arg 6, you probably want to use 0, since the arg isn't a pointer.
You also don't check the return value for success/failure.
printf(count: %d\n,*count);
You then dereference the random piece of memory.
Consider something like:
+++ sysctl.cSat Oct 13 19:08:44 2001
@@ -1,3 +1,4 @@
+#include errno.h
#includestdio.h
#include sys/types.h
#include sys/socket.h
@@ -7,7 +8,9 @@
#include net/if_mib.h
int main(void) {
- int mib[5], *count;
+ int mib[5];
+ int count;
+ int len;
mib[0]=CTL_NET;
mib[1]=PF_LINK;
@@ -15,8 +18,12 @@
mib[3]=IFMIB_SYSTEM;
mib[4]=IFMIB_IFCOUNT;
- sysctl(mib, 5, count, sizeof(int),(void *)NULL, NULL);
-
- printf(count: %d\n,*count);
+ len = sizeof(int);
+ if (sysctl(mib, 5, count, len, NULL, 0) == -1)
+ {
+perror(sysctl);
+exit(1);
+ }
+ printf(count: %d\n,count);
}
--
David Taylor
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Doubt of system(3)
On Tue, 02 Oct 2001, Alfred Perlstein wrote: * Peter Pentchev [EMAIL PROTECTED] [011002 05:21] wrote: On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote: [snip] IMO, the below patch is probably the best solution. Yep, it also fixes the fact that the return value from wait4() needs to be preserved, at least for the return statement of __system(). Aaah! Forgot about it, I'm going to upgrade my workstation now and commit it if it works, probably tonight. If someone else can test it earlier, by all means commit it. Just to say that as I did a make world today, I took the opportunity to test the patch, and it does fix the bug. (Old behaviour: davidt@gattaca:~/C/system-bug$ ./test Parent: Child A pid = 26271 Calling system... Child A: exiting Child B running - pid 26273 Child B: Sending parent (26270) SIGFPE to interrupt wait... System has returned Child B entering busy loop... Child B still running... Parent exiting - child b should have also exited... davidt@gattaca:~/C/system-bug$ Child B still running... killall test2 Terminated New behaviour: davidt@gattaca:~/C/system-bug$ ./test Parent: Child A pid = 27944 Calling system... Child A: exiting Child B running - pid 27946 Child B: Sending parent (27943) SIGFPE to interrupt wait... Child B entering busy loop... Child B still running... Child B still running... Child B still running... ^Z [1]+ Stopped ./test davidt@gattaca:~/C/system-bug$ bg [1]+ ./test davidt@gattaca:~/C/system-bug$ Child B still running... kill 27946 Terminated System has returned Parent exiting - child b should have also exited... davidt@gattaca:~/C/system-bug$ ) However, I won't be able to commit it, since I'm not a committer :) -- David Taylor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Doubt of system(3)
On Sat, 29 Sep 2001, Alfred Perlstein wrote:
* David Taylor [EMAIL PROTECTED] [010929 16:17] wrote:
On Sat, 29 Sep 2001, David Taylor wrote:
If you:
1. Fork, and create a child (say, pid 10)
2. Call system, which forks and creates a child (say, pid 11)
3. Make the child (pid 10) exit now.
3. Interrupt the call to _wait4(pid [=11], ...);
I've now managed to reproduce this...
Test program at http://www.yadt.demon.co.uk/system-bug.tar.gz
I'm pretty sure that's incorrect behaviour, and I also beleive the original
patch posted to this list should fix it...
I should have realized that, especially since I just spent a week
trying to track down the same problem...
*smacks head*
The posted patch is ok, except for the fact that it returns successful
if an rfork thread has reaped the child, another variation is here,
which returns an error ECHILD if someone has reaped our spawed
child, and also keeps EFAULT propogation although that's not going
to happen because of the arguments being on the stack and NULL.
What do you think? Should we silently mask ECHILD? what if wait4()
returns a different error code in the future? Shouldn't we propogate
that?
Well, system(3) claims system() will only return errors from invoking
fork() or waitpid() [which, being pedantic, it doesnt actually invoke]...
Errors from fork() are just passed straight through, so that's ok...
As for wait4(), returning ECHILD from system() doesn't make much sense to me.
We obviously _did_ have a child at some point, and if it went away before
our wait4() call because someone else called wait4() or whatever,
I don't think we should complain. If, somehow, EFAULT is returned, it
should probably get propagated.
However, on second thoughts, since system() is supposed to return the
child's exit status, I'm not sure what to do with ECHILD other than just
propagate it back to the program, since the exit status has already been
given to some other program, and there's no way we can get it. So we either
lie about the exit status and possibly break something that relies on that,
or return a rather unexpected error.
IMO, the below patch is probably the best solution.
cvs diff: Diffing .
Index: system.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/system.c,v
retrieving revision 1.7
diff -u -r1.7 system.c
--- system.c 2001/01/24 13:00:59 1.7
+++ system.c 2001/09/29 21:55:41
@@ -53,7 +53,7 @@
__system(command)
const char *command;
{
- pid_t pid;
+ pid_t pid, savedpid;
int pstat;
struct sigaction ign, intact, quitact;
sigset_t newsigblock, oldsigblock;
@@ -86,8 +86,9 @@
execl(_PATH_BSHELL, sh, -c, command, (char *)NULL);
_exit(127);
default:/* parent */
+ savedpid = pid;
do {
- pid = _wait4(pid, pstat, 0, (struct rusage *)0);
+ pid = _wait4(savedpid, pstat, 0, (struct rusage *)0);
} while (pid == -1 errno == EINTR);
break;
}
--
David Taylor
[EMAIL PROTECTED]
msg28706/pgp0.pgp
Description: PGP signature
Re: Doubt of system(3)
On Sat, 29 Sep 2001, Alfred Perlstein wrote:
* Toshihiko ARAI [EMAIL PROTECTED] [010929 11:10] wrote:
I consider the following code of system(3). pid is changed by return
value of _wait4(). I feel this need a correction.
default:/* parent */
do {
pid = _wait4(pid, pstat, 0, (struct rusage *)0);
} while (pid == -1 errno == EINTR);
break;
Please review and commit this patch.
Why does it need to be corrected? What sort of bad behaviour
are you seeing? You do 'a' and you see 'b' when you should
see 'c'.
What's a, b and c?
Well, hypothetically (I have no time to attempt to set something up to test
this), it looks to me like:
If you:
1. Fork, and create a child (say, pid 10)
2. Call system, which forks and creates a child (say, pid 11)
3. Make the child (pid 10) exit now.
3. Interrupt the call to _wait4(pid [=11], ...);
You _should_ see nothing happen. i.e. system() would simply loop again
until the other child exits.
However, what I think you'd see is system() setting pid == -1, calling
_wait4(-1, ...); and _wait4() returning 10, and system() returning whilst
your child is still running happily away.
If I run out of bugs to squash in ircd, I might try to produce this (I
suppose reproduce is the wrong word, since no one has reported it in the
first place...)
--
David Taylor
[EMAIL PROTECTED]
msg28827/pgp0.pgp
Description: PGP signature
Re: Doubt of system(3)
On Sat, 29 Sep 2001, David Taylor wrote: On Sat, 29 Sep 2001, Alfred Perlstein wrote: Why does it need to be corrected? What sort of bad behaviour are you seeing? You do 'a' and you see 'b' when you should see 'c'. What's a, b and c? Well, hypothetically (I have no time to attempt to set something up to test this), it looks to me like: If you: 1. Fork, and create a child (say, pid 10) 2. Call system, which forks and creates a child (say, pid 11) 3. Make the child (pid 10) exit now. 3. Interrupt the call to _wait4(pid [=11], ...); I've now managed to reproduce this... Test program at http://www.yadt.demon.co.uk/system-bug.tar.gz I'm pretty sure that's incorrect behaviour, and I also beleive the original patch posted to this list should fix it... -- David Taylor [EMAIL PROTECTED] msg28829/pgp0.pgp Description: PGP signature
Re: where to set hw.ata.wc
On Tue, 18 Sep 2001, Karsten W. Rohrbach wrote: John Merryweather Cooper([EMAIL PROTECTED])@2001.09.18 09:43:27 +: An OS upgrade SHOULD only touch /boot/defaults/loader.conf. why is there /boot/loader.conf.local, then? boot.loader(5): /boot/loader.conf user defined settings. /boot/loader.conf.local machine-specific settings for sites with a common loader.conf. So you can have a standard /boot/loader.conf across your site, but still deal with hardware/setup/etc differences. -- David Taylor [EMAIL PROTECTED] PGP signature
Re: testig request for your code..
On Mon, 17 Sep 2001, Julian Elischer wrote: If you find a module that worked in a kernel from before September 11 but does not work on -current, please let [EMAIL PROTECTED] know. NTFS was working correctly in a kernel from sometime in August, it now fails with an easily reproducable panic about locks. Unfortunately, I never wrote down the trace since I was planning on using gdb -k to debug it.. but: # gdb -k kernel.6 vmcore.6 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... (no debugging symbols found)... IdlePTD 4620288 initial pcb at 370340 panicstr: bremfree: bp 0xc8977ba0 not locked panic messages: --- panic: lockmgr: pid 943, not exclusive lock holder 942 unlocking dumping to dev ad0s4b, offset 584197 dump ata0: resetting devices .. done 256 [snip] 1 --- Bus error (core dumped) So, I guess I'll need to copy it down by hand next time I'm prepared to crash my system.. (A simple cd /mnt/w2k/; ls; crashes the box. Oddly enough, it didn't seem to have the same effect in single-user mode, not sure why...) -- David Taylor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: testig request for your code..
On Tue, 18 Sep 2001, Julian Elischer wrote: If you can try a kernel from JUST before the KSE integration.. that migh talso be a good test.. A kernel from cvs up -D2001-09-10 works perfectly, A kernel from after the KSE milestone 2 produces various panics like the following: (find .; running on ntfs partition) | (sleep; god knows where) | ( it came from ) vv panic: lockmgr: pid 30856, not exclusive lock holder 30814 unlocking. backtrace: panic lockmgr vop_stdunlock ntfs_inactive vput lstat Unfortunately, gdb -k kernel.X vmcore.X is still coring on startup, so I can't get any more info, unless someone has something they want me to do at the DDB prompt. -- David Taylor [EMAIL PROTECTED] PGP signature
Re: How to force small TCP packets?
On Mon, 10 Sep 2001, Jonathan Lemon wrote:
One thing you might want to try doing is to write your own read()
function and link against that. Your modified version could then
replace the nbytes value with something smaller, for debugging purposes.
Infact, when I saw this thread I whipped up a simple .so to override the
syscalls to test a network program of my own, and it helpfully found a
obscure bug where I wasn't correctly using the return value from read()..
The main problem with the below code is that it unconditionally reads X
bytes at a time. You might want to override socket/close (and maybe dup
too, if the code does things like that) so you're only restricting syscalls
on sockets. Or make a is_socket() function that does some runtime test I
can't think of to figure out what to do...
(compile using something like:
gcc -fPIC -shared -O2 -g test.c -o test.so;
use with something like:
LD_PRELOAD=/path/to/test.so /your/program/bin/blah)
#define NBYTES 1
ssize_t read(int d, void *buf, size_t nbytes)
{
return syscall(SYS_read, d, buf, ((nbytesNBYTES) ? nbytes : NBYTES));
}
ssize_t write(int d, const void *buf, size_t nbytes)
{
return syscall(SYS_write, d, buf, ((nbytesNBYTES) ? nbytes : NBYTES));
}
--
David Taylor
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sun, 13 May 2001, Karsten W. Rohrbach wrote:
btw, mergemaster's version number generation for the help/syntax page is
broken because it displays the number of the running kernel not the
version of mergemaster itself:
---
VERSION_NUMBER=`grep [$]FreeBSD: $0 | cut -d ' ' -f 4`
echo mergemaster version ${VERSION_NUMBER}
---
That would appear to be mergemaster grepping for the $FreeBSD$ line in
itself, then extracting the CVS revision number from that line.
why is it this way? i would think about creating the version in the
build process and s/@TAG@/version/ it in the to-be-installed mergemaster
file.
The version is branded into the file during the cvs commit process, and is
extracted from the installed file when needed...
--
David Taylor
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: crash dump speed up patch.
On Tue, 27 Mar 2001, Gersh wrote:
it could be replaced with:
if (count % 10)
printf("%d ", count);
that acutally gives alot more output, The basic idea was
to only print out when it got to certian increments 10, 20
Mainly becasue of the problem with serial connections :/
How about
if (!(count % 10))
printf("%d ", count);
So it'd only print every 10..
(Which I think is what was originally intended)
--
David Taylor
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
