Submitted by: Yung-Jen Hung <winard@u3717a.dorm.ccu.edu.tw>
Reviewed by: bearscorp.bbs@bbs.life.nthu.edu.tw
_BIG5_sgetrune() in libc doesn't work well, this commit will fix it.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
o use braces to avoid potentially ambiguous else
o don't default to type int (and also remove a useless register
modifier).
o Use parens around assignment values used as truth values.
o Remove unused function.
Reviewed by: obrien and chuckr
70-00 are intepreted in the 20th century; 01-69 in the
21st century. (Yes, 2000 is the last year of the 20th
century, not the first year of the 21st.)
Submitted by: Sergey Babkin <babkin@bellatlantic.net>
before.
Added SYS.h for mipseb and mipsel.
I now get part way through building libc in the cross environment that
I have (along with pending mipse[bl] changes to the intree egcs) with
these changes.
function. It was an ill-considered feature. It didn't solve the
problem I wanted it to solve. And it added Yet Another Version
Number that would have to be maintained at every release point.
I'm nuking it now before anybody grows too fond of it.
Unlike other filesystem objects, symbolic links do not have an owner,
group, access mode, times, etc. Instead, these attributes are taken from
the directory that contains the link. The only attributes returned from
an lstat() that refer to the symbolic link itself are the file type
(S_IFLNK), size, blocks, and link count (always 1).
This is bogus, and disagrees with the implementation and symlink(7).
Removed it.
PR: docs/10269
Submitted by: Tolik <tolik@sibptus.tomsk.ru>
changes have made this too expensive. This gains about 1.25% on
worldstone on my SMP machine.
Swap-less machines, for instance PicoBSDs, and machines which experience
page-out trafic, check with top(1), will probably want to reenable this
with:
ln -s H /etc/malloc.conf
Suggested by: alc (&dyson ?)
that counted the number of elements in argv. The counter is incremented
in the next-iteration section of the loop, not the body, so at termination
it's already "counted" the element that failed the continuation test - in
this case the NULL argv terminator.
Noted by: bde
call them. All the execX() libc functions should be vfork() safe now.
Specifically:
- execlp() does the argument count-and-build into a vector from alloca
(like the others) - buildargv() is no longer used (and gone).
- execvp() uses alloca/strcpy rather than strdup().
- the ENOEXEC handler uses alloca rather than malloc.
- a couple of free() calls removed - alloca works on the local stack and
the allocations are freed on function exit (which is why buildargv
wasn't useful - it's alloca() context would disappear on return).
Along the way:
- If alloca() fails (can it?), set errno = ENOMEM explicitly.
- The ENOEXEC recovery routine that trys again with /bin/sh appeared to
not be terminating the new argv[] array for /bin/sh, allowing it to
walk off the end of the list.
I dithered a bit about using alloca() even more as it's most commonly
associated with gcc. However, standalone portable (using malloc) and
machine-specific assembler alloca implementations appear to be available
on just about all the architectures we're likely to want to port to.
alloca will be the least of our problems if ever going to another compiler.
kern.chroot_allow_open_directories = 0
chroot(2) fails if there are open directories.
kern.chroot_allow_open_directories = 1 (default)
chroot(2) fails if there are open directories and the process
is subject of a previous chroot(2).
kern.chroot_allow_open_directories = anything else
filedescriptors are not checked. (old behaviour).
I'm very interested in reports about software which breaks when
running with the default setting.
which ones cause us to fail. Now all open errors on the databse file
will cause the next file in the list to be tried.
Submitted by: Arne Henrik Juul <arnej@math.ntnu.no>
PR: 4585
compiling, since <stdio.h> correctly doesn't declare off_t although
the pseudo-prototypes for the new fseeko() and ftello() functions
use it. Handle this like the corresponding problem for va_list
versus the vprintf() family.
Fixed some English errors.
request for it something like it. It was poorly worded and too
far from both POSIX wording and normal (mal)practice by referring to
sysconf(_SC_NGROUPS_MAX) instead of {NGROUPS_MAX} or NGROUPS. POSIX.1
uses curly braces to mark up "symbolic constants or limits [that may
be] defined in certain headers". Since we don't document this markup,
don't use it. Just use NGROUPS_MAX.
so that non-sloppy applications can call it without using disgusting
casts to avoid warnings. The 4th arg is sort of varargs -- it must
sometimes represent a filename, sometimes a struct pointer, and is
sometimes unused. The arg type is still caddr_t in the kernel.
Obtained from: mostly from NetBSD
This changes the definitions of a few items so that structures are the
same whether or not the option itself is enabled. This allows
people to enable and disable the option without recompilng the world.
As the author says:
|I ran into a problem pulling out the VM_STACK option. I was aware of this
|when I first did the work, but then forgot about it. The VM_STACK stuff
|has some code changes in the i386 branch. There need to be corresponding
|changes in the alpha branch before it can come out completely.
what is done:
|
|1) Pull the VM_STACK option out of the header files it appears in. This
|really shouldn't affect anything that executes with or without the rest
|of the VM_STACK patches. The vm_map_entry will then always have one
|extra element (avail_ssize). It just won't be used if the VM_STACK
|option is not turned on.
|
|I've also pulled the option out of vm_map.c. This shouldn't harm anything,
|since the routines that are enabled as a result are not called unless
|the VM_STACK option is enabled elsewhere.
|
|2) Add what appears to be appropriate code the the alpha branch, still
|protected behind the VM_STACK switch. I don't have an alpha machine,
|so we would need to get some testers with alpha machines to try it out.
|
|Once there is some testing, we can consider making the change permanent
|for both i386 and alpha.
|
[..]
|
|Once the alpha code is adequately tested, we can pull VM_STACK out
|everywhere.
|
Submitted by: "Richard Seaman, Jr." <dick@tar.com>
This takes the conditionals out of the code that has been tested by
various people for a while.
ps and friends (libkvm) will need a recompile as some proc structure
changes are made.
Submitted by: "Richard Seaman, Jr." <dick@tar.com>
- document that sysctl() and sysctlbyname() return 0 on success
- if the provided buffer is too small, set errno to ENOMEM and return -1
instead of returning ENOMEM.
is actually mounted on "/" can be determined using statfs() and is
in /dev. This fixes fsck operating on the wrong device when the
fs_spec entry is only an alias. The aliased case became more
dangerous when the ROOTSLICE_HUNT hack was committed in mount(8).
ROOTSLICE_HUNT may be unnecessary now.
Rename 'cerror' to '.cerror' so that programs which have a function or
global variable named 'cerror' don't completely break the syscall error
reporting mechanism.
#include <ieeefp.h>
to access these functions instead of the i386 specific
#include <machine/floatingpoint.h>
Submitted by: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
Submitted by: "Richard Seaman, Jr." <lists@tar.com>
Obtained from: linux :-)
Code to allow Linux Threads to run under FreeBSD.
By default not enabled
This code is dependent on the conditional
COMPAT_LINUX_THREADS (suggested by Garret)
This is not yet a 'real' option but will be within some number of hours.
an unimprovement here. I thought it would be an improvement, as in libkvm,
but here we can access the strings directly.
Use sysctlbyname() instead of sysctl() and trust it to give a nonzero
address if it succeeds.
they cannot mount a filesystem that they cannot see in getvfsbyname().
Part 1 of this is a hack, make vfsisloadable() always return true - the
ultimate decider of whether it's loadable or not is kldload() or mount().
Part 2 of this is to have vfsload() call kldload(2) and return success if
it works. This means that we will use a viable kld module in preference
to an LKM!
Ultimately, the thing to do is remove the hacks to do a vfsload in all the
mount_* commands and let the kernel do it by itself in mount(2).
vfork() can't be used. We could use alloca() in execl() so that
it can be called between vfork() and execve(), but a "portable"
popen() shouldn't depend on this. Calling execle() instead of
execl() should be fairly safe, since execle() is supposed to be
callable from signal handlers and signal handlers can't call
malloc(). However, execle() is broken.
ever saw one), and move the description of NULL behaviour out to a
'NOTES' section, with an extra note that programs should not rely up
on it.
Kinda-approve-by: bde (by not replying to the mail with the diff)
PR: 7923
Submitted by: Archie Cobbs <archie@whistle.com>
The scandir() function returns -1 if it fails.
In many cases when this happens, it does not free
the memory that it allocated, resulting in a memory
leak, or close the directory opened with opendir().
BAD DOG, BAD!
realloc functions check for recursion within the malloc code itself. In
a thread-safe library, the single spinlock ensures that no two threads
go inside the protected code at the same time. The thread implementation
is responsible for ensuring that the spinlock does in fact protect malloc.
There was a window of opportunity in which this was not the case. I'll fix
that with a commit RSN.
string. From the submitted patch:
Credit for patch: Chris Torek <torek@bsdi.com>
Tod Miller <millert@openbsd.org>
This makes us in line with SunOS 4.1.3_U1, Solaris 2.6, OpenBSD 2.3,
HP-UX 10.20, Irix 5.3. The previous behavior was in line with Ultrix 4.4.
PR: bin/7970
Submitted by: Niall Smart nialls@euristix.ie
Our spinlock implementation allows a particular thread to obtain a lock
multiple times, but release the lock with a single unlock call. Since
we're detecting recursion, we know the lock is already owned by the
current thread in a previous call and must not be released in the
current call. This is really far too dependent on this particular
spinlock implementation, so I've added commented out calls to
THREAD_UNLOCK in the appropriate places. We can activate this code when
spinlock is taught to count each lock operation.
In some cases replace if (a == null) a = malloc(x); else a =
realloc(a, x); with simple reallocf(a, x). Per ANSI-C, this is
guaranteed to be the same thing.
I've been running these on my system here w/o ill effects for some
time. However, the CTM-express is at part 6 of 34 for the CAM
changes, so I've not been able to do a build world with the CAM in the
tree with these changes. Shouldn't impact anything, but...
