o In practice: the comment indicates that all but umask and
environmental variables of the users login class are applied when su
occurs, unless -m is used to specify a class. This was incorrect;
in practice, the uid, gids, resources, and priority were set, and
then resources and priority were selectively removed. This meant
that some aspects of the user context were not set, including handling
of login events (wtmp, utmp), as well as the path specified in
login.conf.
o I changed it so that the behavior is the same, but instead,
LOGIN_SETALL is used, and appropriate flags are removed, including
the LOGIN_SETLOGIN and LOGIN_SETPATH entries that were implicitly
not present before. I also updated the comment to reflect
reality, selecting reality as the "correct" behavior.
o This has the practical benefit that as new LOGIN_SET* flags are
introduced, they are supported by su unless specifically disabled.
For example, of a LOGIN_SETLABEL flag is introduced to support
MAC labels determined by the user's login class, then su no longer
has to be modified.
o It might be desirable to have su use LOGIN_SETPATH depending on
its command line parameters, as it might or might not be
considered part of the "environment".
Obtained from: TrustedBSD Project
rc.conf: make the system recognise the MAC address and assign an IP
automatically from /etc/hosts (or ask the user)
sshd_config: don't do x11 forwarding.
/usr/obj hardwired in the code, now you can override it
with a command line option or MAKEOBJDIRPREFIX env. variable.
The above is useful to build picobsd-specific objects in some other
place than /usr/obj
While at it, fix documentation and change a few sprintf -> snprintf.
passed vnode must be locked; this is the case because of calls
to VOP_GETATTR(), VOP_ACCESS(), and VOP_OPEN(). This becomes
more of an issue when VOP_ACCESS() gets a bit more complicated,
which it does when you introduce ACL, Capability, and MAC
support.
Obtained from: TrustedBSD Project
recently discussed at -hackers. The problem is a null-pointer
dereference that happens in kern/vfs_lookup.c when accessing ".."
with a v_mount entry for the current directory vnode of NULL. This
happens when a volume is forcibly unmounted, and the vnode for a
working directory in the mounted volume is cleared.
PR: 23191
Submitted by: Thomas Moestl <tmoestl@gmx.net>
locking the global hash on each uifree()
make struct uidinfo only visible to the kernel
make uihold() a function rather than a macro to reduce bloat
swap the order of a spl/mutex to maintain consistancy
process is on the alternate stack or not. For compatibility
with sigstack(2) state is being updated if such is needed.
We now determine whether the process is on the alternate
stack by looking at its stack pointer. This allows a process
to siglongjmp from a signal handler on the alternate stack
to the place of the sigsetjmp on the normal stack. When
maintaining state, this would have invalidated the state
information and causing a subsequent signal to be delivered
on the normal stack instead of the alternate stack.
PR: 22286
-current and RELENG_4 with GENERIC.
NKPT is the number of initial bootstrap page table pages we create for
the kernel during startup. Once VM is up, we resize it as needed, but
with 4G ram, the size of the vm_page_t structures was pushing it over
the limit. The fact that trimmed down kernels boot on 4G ram machines
suggests that we were pretty close to the edge.
The "30" is arbitary, but smaller than the 'nkpt' variable on all
machines that I checked.
- Use a better test for determining when a process is running.
- Convert some checks to assertions.
- Remove unnecessary tests.
- Save the priority before acquiring a mutex rather than in msleep(9).
4) The cardbus CIS code treats the CIS_PTR as a mapping register if
it is mentioned in the CIS. I don't have a spec handy to understand
why the CIS_PTR is mentioned in the CIS, but allocating a memory range
for it is certainly bogus. My patch ignores bar #6 to prevent the
mapping.
[The pccard spec says that BAR 0 and 7 (-1 and 6 in thic case since we
did a minus one) is "reserved". The off by 1 error has been fixed.
also bar=5 is invalid for IO maps, so we check it.]
5) The CIS code allocated duplicate resources to those already found
by cardbus_add_resources(). The fix is to pass in the bar computed
from the CIS instead of the particular resource ID for that bar,
so bus_generic_alloc_resource succeeds in finding the old resource.
[fixed, also removed superfluous (and incorrect) writing back to the
PCI config space.]
7) The CIS code seems to use the wrong bit to determine rather a particular
register mapping is for I/O or memory space. From looking at the
two cards I have, it seems TPL_BAR_REG_AS should be 0x10 instead
of 0x08. Otherwise, all registers that should be I/O mapped gain
a second mapping in memory space.
[Oops, the spec does say 0x10..., fixed]
Submitted by: Justin Gibbs
