sizeof jail parameter value strings
Hello lists, From jail(3): > The jail_getv() function takes a null-terminated list of name and value > strings, and passes it to jail_get(2). It is the caller's responsibility > to ensure that the value strings point to buffers large enough to hold > the string representation of the returned parameters. What exactly does “large enough” mean here? Is there a way to query the size of the corresponding kernel buffers at runtime? Is there a maximum length à la MAX_JAIL_PARAM_LEN that the string representations of the returned parameters are guaranteed to be shorter than? I’m currently implementing a rust wrapper[1] around the jail(2) interface, and am not sure how large buffers for the string parameters I’m querying with jail_get jail_set have to be. Fabian (I’m not on the freebsd-jail mailing list, so I’d appreciate being kept in the CC) [1] https://github.com/fubarnetes/libjail-rs signature.asc Description: OpenPGP digital signature
Re: sizeof jail parameter values
[reordered parts of the reply for better reading flow]
On 05/18/2018 18:49, James Gritton wrote:
I would recommend skipping out on jail_getv(), which is really only
good for getting a few well-known parameters, and instead use the more
complete but more complex jailparam_init/get/export/free.
Thanks! I ended up writing wrappers around the jail_get(2) and
jail_set(2) interfaces and constructing the iovectors myself, which
ended up quite a bit cleaner. The jailparam_{init,get,export,free} APIs
are unnecessarily complex and don't seem to be a good fit (writing
wrappers around wrappers around wrappers etc...).
There is a way to find the length of a string parameter, though there
isn't a good library interface for it. The security.jail.param.*
sysctls describe the form of the parameters, giving the type. The
"contents" of these sysctls are generally unused (and set to zero), but
for string parameters there's actually the max length of the string
(itself in string form).
Thanks, this works great for strings!
For non-string parameters, the length in
string form depends on the type of the parameters, so for an int you'll
need as long as the string representation of an ant can be, etc. I
don't know how much good C code will do for you for Rust work, but you
might want to take a look at jailparam_type() in the libjail source code.
It gets more complicated with array parameters, those that can hold an
arbitrary number of values. The IP addresses are the best example of
that.
I've now hit that snag. I see that the security.jail.param.ip4.addr and
security.jail.param.ip6.addr sysctls contain the sizes of an in_addr_t
and an in6_addr_t, respectively. How would I now determine the number of
IPv4 and IPv6 addresses, or should I just allocate
security.jail.jail_max_af_ips per family? I've tried to go through how
libjail does it, but don't quite understand it, nor the implied race
conditions (?) it attempts to mitigate by reading the vector multiple times:
lib/libjail/jail.c:
/*
* Get the prison. If there are array elements, retry a few times
* in case their sizes changed from under us.
*/
for (sanity = 0;; sanity++) {
[...]
Fabian
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
kqueue(2) kevents for jails
Hi! I'm writing a jail management library [1], and am wondering if there's any nice way to get notified of jail state changes (especially running -> dying -> dead) as well as of parameter changes. What are the opinions on adding a kevent(2) for these things? Fabian [1] https://github.com/fubarnetes/libjail-rs/ ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: kqueue(2) kevents for jails
On 1/4/19 6:20 PM, Christian Barthel wrote: I worked on something similar (not a library but more acting like a daemon). The way I managed Jails was by forking a jail(8) process and collecting the exit status. Not sure if that is possible for your library case. Yes, I've thought about doing things like that too, like double-forking and having the parent wait for the jailed child, but those all seem dirty to me. Ideally, I'd like to register callbacks on jail state change to clean up file systems etc. On 1/4/19 5:14 PM, Konstantin Belousov wrote: No, kevent(2) is not suitable mechanism to notify about jail state changes. If anything in the existing system can be reused for such notifications, it is devctl(4) notifications which are handled by devd(8). Look at the man pages and for existing notifications in kernel code, e.g. sys/kern/kern_conf.c notify*() for how devfs does it. Can any running binary subscribe to devd(8) events or does that require a configuration change in /etc/devd.conf? ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: kqueue(2) kevents for jails
On 1/4/19 9:29 PM, Konstantin Belousov wrote: On Fri, Jan 04, 2019 at 09:11:58PM +0100, Fabian Freyer wrote: On 1/4/19 5:14 PM, Konstantin Belousov wrote: No, kevent(2) is not suitable mechanism to notify about jail state changes. If anything in the existing system can be reused for such notifications, it is devctl(4) notifications which are handled by devd(8). Look at the man pages and for existing notifications in kernel code, e.g. sys/kern/kern_conf.c notify*() for how devfs does it. Can any running binary subscribe to devd(8) events or does that require a configuration change in /etc/devd.conf? Only one reader is supported, effectively. devctl(4) tries to limit opens naively. But then even if you have the file descriptor and fork or pass it over unix domain socket, single event can be only read by one reader. Ah, I see, thanks! Is there any other nice notification mechanism that a process could 'subscribe' to to be notified of an event? I am still a bit confused as to why knotify would be such a bad fit, maybe you could expand a bit on that? Not least because jail creation/destruction is relatively low frequency events with potentially rich secondary information that should be attached to them. Kevents are high-frequency, high-performance kind of events, Does this mean they cannot nicely be used for lower-frequency things? I'm thinking of situations where jails may get spawned e.g. per-network-request. and only naturally tied to file descriptors. according to kevent(2), EVFILT_PROC Takes the process ID to monitor as the identifier so there's also cases where it isn't tied to a file descriptor, but some other descriptor (pid's don't seem to be too different to jid's?) There were lot of bugs in integration of kevents with e.g. processes notifications, and API is still somewhat racy Is this a kevents issue or an integration problem? In the end, might it be a good idea to add devctl(4) notifications as well as kevent(2)? ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
[call for testing] kmod-devctl-jail
Hi all, I'd like to call for testing of the kernel module kmod-devctl-jail [1], which adds devctl(4) support for jail state changes. The aim is to provide some logging and/or auditing support as well as providing jail managers with a way to get notified of jail state changes. I'm not yet clear as to whether this is something that could/should get upstreamed into base, or should better live in ports. Please CC me when replying to this, as I am not subscribed to freebsd-jail@. Thanks, Fabian [1] https://github.com/fubarnetes/kmod_devctl_jail.git ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
