We now have a Publisher to report on disk events and its metadata,
using the DiskArbitration framework on OS X. Currently disk appearance
and disappearance events are published for both physical and
virtual disks (DMG files). On an event trigger, disk properties are
parsed and that metadata is reported along with the action.
The Subscriber subscribes to virtual disk events currently.
This closes#1103.
`int osquery::filter(const struct dirent*)` seemed like a pretty generic
symbol to have in our symbol table, so I changed it to
`int msrScandirFilter(const struct dirent*)`
This infomation is primarily related to the performance of processor
cores. The information given constitutes only a small portion of
the information in the model specific register, but this table
has been designed so that more information may easily be added.
The table requires osquery be run as the root, and that the msr
kernel module is loaded. The table reads the msr data from /dev
1. Example queries will run with an (optional) integration test.
2. Fix bad accesses with OS X package BOMs
3. Move spec files from ./osquery/tables/specs to ./specs
4. Remove server parsers (netlib) from client builds.
This change allows QueryContext constraints to be checked for based on
operator type. This makes checks for the existence of an equality
operator allow enumeration.
Example:
if (context.constraints["pid"].exists(EQUALS)) {
pids = context.constraints["pid"].getAll(EQUALS);
} else {
osquery::procProcesses(pids);
}
This implements the following tables on FreeBSD:
process_envs
process_memory_map
process_open_files
process_open_sockets
processes
All the heavy lifting is done with libprocstat(3). All the tables follow
the same general principle. Use the common function, getProcesses() in
procstat.cpp, to get the processes and then generate the rows for each
process returned. There is also a procstatCleanup() function commonly
used across all the tables.
The one thing I am not able to test is the process_open_sockets table on
an IPv6 machine.
The user_groups table represents the association between user ids and group ids.
Darwin Issue:
Issues arise in darwin systems with users that are members of many groups due
to a bug in Apple's implementation of getgrouplist. If the number of groups a
user is a member of is greater than 64 a truncated association table may
be returned.
