OK for the man page change. Make sure to bump the .Dd when you commit it for this content change.
Thanks for working on this, it's appreciated!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 11 2024
- make some scripts compatible with svcj (convert parts of the precmd into another way of settings variables), precmd is not run inside the same shell/jail = make it work with svcj
- add some support for nfs in svcj, not yet finished (precmd is not comaptible)
- exclude some scripts from svcj due to an incompatible precmd (not run in same shell/jail)
Make jls quiet.
Nov 28 2023
Nov 24 2023
Only rc.d/opensm is missing.
Nov 16 2023
Add support for nfs. Sort the options.
Add config for some more services.
Nov 10 2023
Change what was noticed in comments. Add a feature to enable the execution of extra commands inside the service jail.
Oct 16 2023
In D40188#920799, @jamie wrote:Commited in eb5bfdd06565. I forgot to add the review to the commit message :-/
Oh and we also have to close it, because it did land! ugh Phabricator is very Project-Management-y :)
In D40188#920799, @jamie wrote:Commited in eb5bfdd06565. I forgot to add the review to the commit message :-/
In D38826#920142, @ihor_antonovs.family wrote:IMHO this is superseded by https://reviews.freebsd.org/D40188
Oct 5 2023
Two fixes for the man page.
Sep 21 2023
Sep 15 2023
The overall idea seems ok to me for what it's worth, my comments are about cosmetic issues.
Jul 11 2023
Jun 19 2023
Jun 15 2023
Jun 14 2023
My comments have been addressed and I think it makes sense to go ahead with the proposed patches.
Jun 13 2023
In D40377#922101, @nyan_myuji.xyz wrote:In D40377#922083, @crest_freebsd_rlwinm.de wrote:The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.
Static storage are always initialized to 0/NULL by C standard.
Jun 12 2023
In D40377#922083, @crest_freebsd_rlwinm.de wrote:The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.
The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.
Jun 9 2023
Jun 7 2023
Commited in eb5bfdd06565. I forgot to add the review to the commit message :-/
Jun 6 2023
Jun 5 2023
Jun 4 2023
I've committed the "jails can include jails" and "use the recursive parser" bits separately. This new diff is just the part that handles the includes.
IMHO this is superseded by https://reviews.freebsd.org/D40188
Jun 1 2023
In D40188#919081, @crest_freebsd_rlwinm.de wrote:Just a small nitpick: I would prefer a macro #define MAX_INCLUDE_DEPTH 32
Just a small nitpick: I would prefer a macro #define MAX_INCLUDE_DEPTH 32 or constant static const unsigned int max_include_depth = 32; somewhere above the include_config() in config.c instead of the literal to improve readability.
May 31 2023
Simple include-loop prevention with via a maximum depth counter.
May 23 2023
True, they're not handled. I took my include inspiration from newsyslog (which has includes that also support globbing), and there it's also just a simple matter or running whatever it's told to include. It's kind of a footgun situation, where it's generally good enough to trust the administrator not to make such a loop. I did it for depend loops, but only because that's kind of elemental in building an acyclic directed graph.
It doesn't look like the patch in it's current state handles this circular includes.
In D40188#915660, @dvl wrote:In D40188#915159, @otis wrote:Haven't looked closely yet, but: are circular includes handled correctly?
This is what I came here to ask.
May 22 2023
In D40188#915159, @otis wrote:Haven't looked closely yet, but: are circular includes handled correctly?
Haven't looked closely yet, but: are circular includes handled correctly?
May 21 2023
I you use git format-patch -1 -U9999 and apply it with git am <patch>, you get the whole commit with the message. Not strictly needed, but makes life easier.
I like this approach.
It blurs the line between UCL and jail format (IMHO making future transition to UCL smoother), and makes include more explicit (and less magical comparing to D40188)
New and improved diff :-)
@jamie please re-generate the diff with -U9999 and re-upload it. This is necessary to have context available. (Annoying Phab limitation when diffs are uploaded manually)
May 10 2023
May 5 2023
Mar 27 2023
I suggest we start with a switch which enables the new solution. That means it does not break stuff for people who upgrade.
Mar 26 2023
In D38826#894218, @guest-patmaddox wrote:In D38826#887279, @dvl wrote:All jails.conf jail (in /etc/jail.conf, /etc/jail.*.conf and /etc/jail.conf.d/*.conf) start automatically, without the need to define them in jail_list in rc.conf
That will require an UPDATING notice.
AND: perhap a switch[es] to preserve the old behavior and if set, enable the new behavior.
What is the motivation for changing the default behavior in the first place?
I have a bunch of “utility” jails that I don’t want starting up on boot. If it does change to start all jails, there either needs to be a way to maintain old behavior with an inclusion list, or at least provide an exclusion list to prevent some jails from starting.
I prefer the current behavior with inclusion lists. You have to enable most services - starting all jails by default conflicts with that general principle. Starting all jails - with no way to exclude them - would cause a big problem for me.
In D38826#887279, @dvl wrote:All jails.conf jail (in /etc/jail.conf, /etc/jail.*.conf and /etc/jail.conf.d/*.conf) start automatically, without the need to define them in jail_list in rc.conf
That will require an UPDATING notice.
AND: perhap a switch[es] to preserve the old behavior and if set, enable the new behavior.
Mar 25 2023
Mar 15 2023
Mar 11 2023
This change conflicts with https://reviews.freebsd.org/D39011
@antranigv_freebsd.am and @meka_tilda.center need to hash this out
Mar 8 2023
All jails.conf jail (in /etc/jail.conf, /etc/jail.*.conf and /etc/jail.conf.d/*.conf) start automatically, without the need to define them in jail_list in rc.conf
Mar 1 2023
In D38826#884016, @jlduran_gmail.com wrote:I like the overall idea, thank you for adding more conf.ds to FreeBSD!
Something I do not understand: My "dormant", cron-initiated jails will always start upon boot (i.e., /etc/jail.anotherjail.conf, while anotherjail not in jail_list)?
Regarding the code itself, wouldn't it be better to create a function, something like:
all_jail_confs() { local jail_conf_locations jail_conf_locations="$jail_conf $jail_conf_dir/*.conf /etc/jail.*.conf" if [ -f "$1" ]; then jail_conf_locations="$1 $jail_conf_locations" fi cat $jail_conf_locations 2>/dev/null }And use it instead of repeating the same code in 5 places?
I like the overall idea, thank you for adding more conf.ds to FreeBSD!
Feb 28 2023
To add a bit of context from a conversation on IRC, this review is intended to make it much easier to define jail(8) variables globally at the top of jail.conf(5), you only need to instanciate the name of a jail and optionally some per-jail values.
- Remove the memo and add jail_conf_dir
Feb 23 2023
Jan 18 2023
In D34563#865612, @zlei wrote:I think this patch also apply to stable/12.
I'd like to MFC it to stable/12, @markj do you have any objections ?
I think this patch also apply to stable/12.
I'd like to MFC it to stable/12, @markj do you have any objections ?
Sep 21 2022
In D34579#828698, @glebius wrote:I can't see how this can be used maliciously, e.g. forcing some application outside of jail to send its SCM_RIGHTS to a jail.
Sep 8 2022
I can't see how this can be used maliciously, e.g. forcing some application outside of jail to send its SCM_RIGHTS to a jail. Even if such case exists for a certain application, that would be bug in that application, IMHO. The initial idea of SCM_RIGHTS was actually to grant rights intentionally, so there can be a valid case for a certain application that wants to grant rights to its peer in a jail.
Jun 21 2022
Jun 3 2022
May 28 2022
@trasz could you please say something about this?
May 24 2022
In D34563#799888, @zlei.huang_gmail.com wrote:I do not have direct access to the repository, @markj may you please commit this?
See also D35304
In D34563#799891, @me_igalic.co wrote:In D34563#784083, @markj wrote:Seems reasonable. I think /dev/log is legacy anyway.
does that mean i don't have to change anything about D27411 once this gets committed?
May 23 2022
In D34563#784083, @markj wrote:Seems reasonable. I think /dev/log is legacy anyway.
I do not have direct access to the repository, @markj may you please commit this?
May 16 2022
Ping
Mar 30 2022
Found a race between sys_exit() -> exit1() -> thread_exit() and sys_wait() -> proc_reap().
Slightly moving down PROC_SUNLOCK() in thread_exit() to protect RACCT_RT calculations from proc_reap() destroying p->p_racct.
Mar 29 2022
For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail.
I'm going to have to sleep on the approach. This is a known escape, but I don't know if the method used can fully plug it. For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail. As is it does solve it for processes which have no way to talk to each other apart from a partially shared fs though.
Mar 28 2022
Mar 25 2022
I'll prod someone time-related to have a look at the rest of the patch.
Mar 23 2022
Mar 22 2022
I can't comment on time keeping, but I have some other stuff.