Limit routing socket so only poll(2) and read(2) are allowed (CAP_POLL_EVENT
and CAP_READ). This prevents unprivileged process from adding, removing or
modifying system routes.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
- Limit bpf descriptor in unprivileged process to CAP_POLL_EVENT, CAP_READ and
allow for SIOCGIFFLAGS, SIOCGIFMEDIA ioctls.
- While here limit bpf descriptor in privileged process to only CAP_WRITE.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Currently it was allowed to send any UDP packets from unprivileged process and
possibly any packets because /dev/bpf was open for writing.
Move sending packets to privileged process. Unprivileged process has no longer
access to not connected UDP socket and has only access to /dev/bpf in read-only
mode.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
- Add new request (IMSG_SEND_PACKET) that will be handled by privileged process.
- Add $FreeBSD$.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
The gethostname(3) function won't work in capability mode, because reading
kern.hostname sysctl is not permitted there. Cache hostname early and use
cached value later.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Make use of two fields: rfdesc and wfdesc to keep bpf descriptor open for
reading only in rfdesc and bpf descriptor open for writing only in wfdesc.
In the end they will be used by two different processes.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
but ACM formula we use have internal state (and return value) in the
[1, 0x7ffffffe] range, so our RAND_MAX (0x7fffffff) is never reached
because it is off by one, zero is not reached too.
Correct both RAND_MAX and rand(3) return value, shifting last one
to the 0 by 1 subtracted, resulting POSIXed [0, 0x7ffffffd(=new RAND_MAX)]
range.
2) Add a checks for not overflowing on too big seeds. It may happens on
the machines, where sizeof(unsigned int) > 32 bits.
Reviewed by: bde [1]
MFC after: 2 weeks
capabilities.
rwhod(8) receiver can now only receive packages, write to /var/rwho/ directory
and log to syslog.
Submitted by: Mariusz Zaborski <oshogbo@FreeBSD.org>
Sponsored by: Google Summer of Code 2013
Reviewed by: pjd
MFC after: 1 month
which is very bad idea. Split sending and receiving in two processes,
which fixes this problem and will help to sandbox rwhod.
Submitted by: Mariusz Zaborski <oshogbo@FreeBSD.org>
Sponsored by: Google Summer of Code 2013
Reviewed by: pjd
MFC after: 1 month
we are probing a PCI-PCI bridge it is because we found one by enumerating
the devices on a PCI bus, so the bridge is definitely present. A few
BIOSes report incorrect status (_STA) for some bridges that claimed they
were not present when in fact they were.
While here, move this check earlier for Host-PCI bridges so attach fails
before doing any work that needs to be torn down.
PR: kern/91594
Tested by: Jack Vogel @ Intel
MFC after: 1 week
a macro with parameters. Remove a __DECONST hack and add consts instead
for gnu libiconv API compatability. This makes it work with things like
devel/boost-libs that expects to use "iconv" as though it were a pointer.
would sometimes result in a corrupted file was reported via email.
This problem appears to have been caused by r251719 (reverting
r251719 fixed the problem). Although I have not been able to
reproduce this problem, I suspect it is caused by another thread
increasing np->n_size after the mtx_unlock(&np->n_mtx) but before
the vnode_pager_setsize() call. Since the np->n_mtx mutex serializes
updates to np->n_size, doing the vnode_pager_setsize() with the
mutex locked appears to avoid the problem.
Unfortunately, vnode_pager_setsize() where the new size is smaller,
cannot be called with a mutex held.
This patch returns the semantics to be close to pre-r251719 (actually
pre-r248567, r248581, r248567 for the new client) such that the call to
vnode_pager_setsize() is only delayed until after the mutex is
unlocked when np->n_size is shrinking. Since the file is growing
when being written, I believe this will fix the corruption.
A better solution might be to replace the mutex with a sleep lock,
but that is a non-trivial conversion, so this fix is hoped to be
sufficient in the meantime.
Reported by: David G. Lawrence (dg@dglawrence.com)
Tested by: David G. Lawrence (to be done soon)
Reviewed by: kib
MFC after: 1 week
