Re: Capsicum project: Ideas needed

On 07/07/11 20:42, Ilya Bakulin wrote: Hi hackers, As a part of ongoing effort to enhance usage of Capsicum in FreeBSD base system, I want to ask you, which applications in the base system should receive sandboxing support. So far, the following applications were sandboxed during initial Capsicum

Re: Capsicum project: Ideas needed

On Thu, Jul 7, 2011 at 8:42 PM, Ilya Bakulin wrote: > Hi hackers, > As a part of ongoing effort to enhance usage of Capsicum in FreeBSD base > system, I want to ask you, which applications in the base system should > receive sandboxing support. > So far, the following applications were sandboxed d

Capsicum project: Ideas needed

Hi hackers, As a part of ongoing effort to enhance usage of Capsicum in FreeBSD base system, I want to ask you, which applications in the base system should receive sandboxing support. So far, the following applications were sandboxed during initial Capsicum research project: sshd: critical system

mips xlr system for direct compiling

I have been working on cross compiling some software for MIPS XLR. I found it would be quicker if I direct compile. Can some one recommend a MIPS XLR system that I could have at home for doing some development work on? Or is the possible compiler farm I might get access to . ___

Re: pri_to_rtp returns invalid initial priority

On Thursday, July 07, 2011 6:37:02 am Dmitry Krivenok wrote: > Hi Hackers, > I've developed a simple kld which demonstrates a problem I found on my > FreeBSD-8.2. Maybe revision 222802? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http:

Possible to see which requests are in queue contributing to system load?

top(1) shows the load as a number supposedly equal to the resource queue length. But is there a way to detail this information? For example I want the system to log which requests to which files by which process/thread are in the queue and when they are fulfilled by the scheduler? Yuri __

Re: [PATCH] avoid assuming MAXPATHLEN in config(8)

* Robert Millan , 20110707 13:12: > As for the __GLIBC__ bit, it is difficult to handle this without a > function that canonicalizes arbitrary-length pathnames. Would you > prefer something like: > > #ifdef MAXPATHLEN > // use realpath on a statically-allocated buffer &

Re: Jails: Setting different times in jails

> possibly achievable in libc? I don't know. Where else would it be done? stat, utimes, gettimeofday, clock_gettime, adjtime, etc and their variations. I've not checked what currently happens, but I don't think root in a jail should be able to set any kernel time parameters, absent a syscall that

Re: [PATCH] avoid assuming MAXPATHLEN in config(8)

2011/7/7 Ed Schouten : > * Robert Millan , 20110707 11:33: >> config(8) assumes MAXPATHLEN is defined in a few places, but presence >> of this macro isn't garanteed (POSIX says that it is only present when >> a file length limit exists, which may not be the case). >

pri_to_rtp returns invalid initial priority

Hi Hackers, I've developed a simple kld which demonstrates a problem I found on my FreeBSD-8.2. / #include #include #include #include #include #include #include #include #include #include #include

Re: [PATCH] avoid assuming MAXPATHLEN in config(8)

Hi Robert, * Robert Millan , 20110707 11:33: > config(8) assumes MAXPATHLEN is defined in a few places, but presence > of this macro isn't garanteed (POSIX says that it is only present when > a file length limit exists, which may not be the case). Even though it is good to make ou

[PATCH] avoid assuming MAXPATHLEN in config(8)

config(8) assumes MAXPATHLEN is defined in a few places, but presence of this macro isn't garanteed (POSIX says that it is only present when a file length limit exists, which may not be the case). This patch fixes a usr.sbin/config compile problem on Debian GNU/Hurd by using dynamic allocation. D