summaryrefslogtreecommitdiffstats
path: root/sbin/hastd/subr.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge an applicable subset of r263234 from HEAD to stable/10:rwatson2015-03-191-1/+1
| | | | | | | | | | | | | Update most userspace consumers of capability.h to use capsicum.h instead. auditdistd is not updated as I will make the change upstream and then do a vendor import sometime in the next week or two. Note that a significant fraction does not apply, as FreeBSD 10 doesn't contain a Capsicumised ping, casperd, libcasper, etc. When these features are merged, the capsicum.h change will need to be merged with them. Sponsored by: Google, Inc.
* Change the cap_rights_t type from uint64_t to a structure that we can extendpjd2013-09-051-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the future in a backward compatible (API and ABI) way. The cap_rights_t represents capability rights. We used to use one bit to represent one right, but we are running out of spare bits. Currently the new structure provides place for 114 rights (so 50 more than the previous cap_rights_t), but it is possible to grow the structure to hold at least 285 rights, although we can make it even larger if 285 rights won't be enough. The structure definition looks like this: struct cap_rights { uint64_t cr_rights[CAP_RIGHTS_VERSION + 2]; }; The initial CAP_RIGHTS_VERSION is 0. The top two bits in the first element of the cr_rights[] array contain total number of elements in the array - 2. This means if those two bits are equal to 0, we have 2 array elements. The top two bits in all remaining array elements should be 0. The next five bits in all array elements contain array index. Only one bit is used and bit position in this five-bits range defines array index. This means there can be at most five array elements in the future. To define new right the CAPRIGHT() macro must be used. The macro takes two arguments - an array index and a bit to set, eg. #define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL) We still support aliases that combine few rights, but the rights have to belong to the same array element, eg: #define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL) #define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL) #define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP) There is new API to manage the new cap_rights_t structure: cap_rights_t *cap_rights_init(cap_rights_t *rights, ...); void cap_rights_set(cap_rights_t *rights, ...); void cap_rights_clear(cap_rights_t *rights, ...); bool cap_rights_is_set(const cap_rights_t *rights, ...); bool cap_rights_is_valid(const cap_rights_t *rights); void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src); void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src); bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little); Capability rights to the cap_rights_init(), cap_rights_set(), cap_rights_clear() and cap_rights_is_set() functions are provided by separating them with commas, eg: cap_rights_t rights; cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT); There is no need to terminate the list of rights, as those functions are actually macros that take care of the termination, eg: #define cap_rights_set(rights, ...) \ __cap_rights_set((rights), __VA_ARGS__, 0ULL) void __cap_rights_set(cap_rights_t *rights, ...); Thanks to using one bit as an array index we can assert in those functions that there are no two rights belonging to different array elements provided together. For example this is illegal and will be detected, because CAP_LOOKUP belongs to element 0 and CAP_PDKILL to element 1: cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL); Providing several rights that belongs to the same array's element this way is correct, but is not advised. It should only be used for aliases definition. This commit also breaks compatibility with some existing Capsicum system calls, but I see no other way to do that. This should be fine as Capsicum is still experimental and this change is not going to 9.x. Sponsored by: The FreeBSD Foundation
* Now that ioctl(2) is allowed in capability mode and we can limit ioctls for thepjd2013-03-141-16/+48
| | | | | | | | | given descriptors, use Capsicum sandboxing for hastd in primary and secondary modes. Allow for DIOCGDELETE and DIOCGFLUSH ioctls on provider descriptor and for G_GATE_CMD_MODIFY, G_GATE_CMD_START, G_GATE_CMD_DONE and G_GATE_CMD_DESTROY on GEOM Gate descriptor. Sponsored by: The FreeBSD Foundation
* For functions that return -1 on failure check exactly for -1 and not forpjd2012-01-101-4/+4
| | | | | | any negative number. MFC after: 3 days
* Constify argument.pjd2012-01-061-1/+1
| | | | MFC after: 3 days
* No need to use KEEP_ERRNO() macro around pjdlog functions, as they don'tpjd2011-09-271-19/+17
| | | | | | modify errno. MFC after: 3 days
* Compile capsicum support only if HAVE_CAPSICUM is defined.pjd2011-06-271-0/+4
| | | | MFC after: 3 days
* Log a warning if we cannot sandbox using capsicum, but only under debug level 1.pjd2011-06-271-2/+6
| | | | | | | It would be too noisy to log it as a proper warning as CAPABILITIES are not compiled into GENERIC by default. MFC after: 3 days
* To handle BIO_FLUSH and BIO_DELETE requests in secondary worker we needpjd2011-05-231-1/+7
| | | | | | | to use ioctl(2). This is why we can't use capsicum for now to sandbox secondary. Capsicum is still used to sandbox hastctl. MFC after: 1 week
* Currently we are unable to use capsicum for the primary worker process,pjd2011-05-141-18/+40
| | | | | | | | | | | | | | | | | because we need to do ioctl(2)s, which are not permitted in the capability mode. What we do now is to chroot(2) to /var/empty, which restricts access to file system name space and we drop privileges to hast user and hast group. This still allows to access to other name spaces, like list of processes, network and sysvipc. To address that, use jail(2) instead of chroot(2). Using jail(2) will restrict access to process table, network (we use ip-less jails) and sysvipc (if security.jail.sysvipc_allowed is turned off). This provides much better separation. MFC after: 1 week
* When using capsicum to sanbox, still use other methods first, just in casepjd2011-05-141-10/+13
| | | | one of them have some problems.
* Add my copyright.pjd2011-03-221-0/+1
| | | | MFC after: 1 week
* White space cleanups.pjd2011-03-221-4/+4
| | | | MFC after: 1 week
* When dropping privileges prefer capsicum over chroot+setgid+setuid.pjd2011-03-211-1/+15
| | | | | | | | | We can use capsicum for secondary worker processes and hastctl. When working as primary we drop privileges using chroot+setgid+setuid still as we need to send ioctl(2)s to ggate device, for which capsicum doesn't allow (yet). X-MFC after: capsicum is merged to stable/8
* Add snprlcat() and vsnprlcat() - the functions I'm always missing.pjd2011-03-211-0/+24
| | | | | | | They work as a combination of snprintf(3) and strlcat(3) - the caller can append a string build based on the given format. MFC after: 1 week
* Let the caller log info about successful privilege drop.pjd2011-02-031-2/+0
| | | | | | We don't want to log this in hastctl. MFC after: 1 week
* - Use pjdlog for assertions and aborts as this will log assert/abort messagepjd2011-01-311-2/+2
| | | | | | | | | to syslog if we run in background. - Asserts in proto.c that method we want to call is implemented and remove dummy methods from protocols implementation that are only there to abort the program with nice message. MFC after: 1 week
* Implement function that drops privileges by:pjd2011-01-281-0/+72
| | | | | | | | | | - chrooting to /var/empty (user hast home directory), - setting groups to 'hast' (user hast primary group), - setting real group id, effective group id and saved group id to 'hast', - setting real user id, effective user id and saved user id to 'hast'. At the end verify that those operations where successfull. MFC after: 1 week
* Please welcome HAST - Highly Avalable Storage.pjd2010-02-181-0/+118
HAST allows to transparently store data on two physically separated machines connected over the TCP/IP network. HAST works in Primary-Secondary (Master-Backup, Master-Slave) configuration, which means that only one of the cluster nodes can be active at any given time. Only Primary node is able to handle I/O requests to HAST-managed devices. Currently HAST is limited to two cluster nodes in total. HAST operates on block level - it provides disk-like devices in /dev/hast/ directory for use by file systems and/or applications. Working on block level makes it transparent for file systems and applications. There in no difference between using HAST-provided device and raw disk, partition, etc. All of them are just regular GEOM providers in FreeBSD. For more information please consult hastd(8), hastctl(8) and hast.conf(5) manual pages, as well as http://wiki.FreeBSD.org/HAST. Sponsored by: FreeBSD Foundation Sponsored by: OMCnet Internet Service GmbH Sponsored by: TransIP BV
OpenPOWER on IntegriCloud