some symbols of libc may be resolved by RTLD internal entities.

2007-01-30 Thread takawata
Hi, It seems that some symbols in libc is resolved by libc entities which is linked with RTLD to implement it. % nm -D ld-elf.so.1 ... 000158ec T mmap c4fc W mprotect c4dc W munmap ... And running Flash9 with Symbol Versioning-aware Linux Plugin Wrapper shows that mmap cannot be

Re: some symbols of libc may be resolved by RTLD internal entities.

2007-01-30 Thread Alexander Kabaev
On Tue, 30 Jan 2007 18:00:46 +0900 [EMAIL PROTECTED] wrote: Hi, It seems that some symbols in libc is resolved by libc entities which is linked with RTLD to implement it. % nm -D ld-elf.so.1 ... 000158ec T mmap c4fc W mprotect c4dc W munmap ... It doesn't. rtld is a special

top delay value

2007-01-30 Thread waldeck
Hello, An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). Is there any possibility to deactivate this functionality without recompilation? There are other top implementations that use a secure mode configuration which avoids the setting

Re: top delay value

2007-01-30 Thread Oliver Fromme
[EMAIL PROTECTED] wrote: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). Well, an unprivileged user can achieve the same effect by typing while :; do :; done. There are a thousand ways to waste CPU time, and there is no way to

Re: top delay value

2007-01-30 Thread Dan Nelson
In the last episode (Jan 30), [EMAIL PROTECTED] said: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). Are you sure? In 6.2 at least, s0 in interactive mode results in a 1-second delay, and top -s0 prints top: warning: seconds delay

Re: top delay value

2007-01-30 Thread Mike Meyer
In [EMAIL PROTECTED], [EMAIL PROTECTED] typed: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). No, they can't. Should they use the interactive facility to set the delay to 0 (you can't do that via the -s switch), then top will compete

Re: top delay value

2007-01-30 Thread Stephen Montgomery-Smith
Dan Nelson wrote: In the last episode (Jan 30), [EMAIL PROTECTED] said: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). Are you sure? In 6.2 at least, s0 in interactive mode results in a 1-second delay, and top -s0 prints top:

Re: top delay value

2007-01-30 Thread Dr. Markus Waldeck
Well, an unprivileged user can achieve the same effect by typing while :; do :; done. There are a thousand ways to waste CPU time, and there is no way to prevent a user from doing it. It is not the same effect. You describe fork bombing. Many forked processes eat up the CPU. I could limit

Re: top delay value

2007-01-30 Thread Joerg Sonnenberger
On Tue, Jan 30, 2007 at 05:23:50PM +0100, Dr. Markus Waldeck wrote: Well, an unprivileged user can achieve the same effect by typing while :; do :; done. There are a thousand ways to waste CPU time, and there is no way to prevent a user from doing it. It is not the same effect. You

ptrace equivalents between freebsd and linux?

2007-01-30 Thread Steve Kargl
MPICH2 has the ability to use shared memory as one of its communication channel. Unfortuantely, the build dies with an error realted to ptrace. In looking at a linux manpage for ptrace, I've identified that the linux PTRACE_ATTACH and PTRACE_DETACH are equilavent to out PT_ATTACH and PT_DETACH.

pin/bind a pthread to a processor? (take 2)

2007-01-30 Thread John Giacomoni
Previously when I asked this question it turned out to not be as necessary as I thought. However, I now need a way to pin/bind a user-space thread to a processor until I'm done with it as my timing constraints are too tight to account for. I checked sys/sched.h, sys/proc.h, pthread.h, and

a question regarding sys/shm.h

2007-01-30 Thread Pascal Hofstee
Hi, In a recent attempt in trying to clean up some compiler warnings in a GNUstep related project i came upon a case where the FreeBSD datatypes seemed to disagree with the Linux ones. Though this in itself is not unusual i do wonder if in this case the Linux definition isn't the more proper