Also, the jail.8 man page should have the parameter, which is a good place to mention the requirements for using it.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 10 2022
Dec 9 2022
What's the purpose of nfsd_call_vnet_cleanup being a function pointer? If it's because you need VNET_NFSD for it to exist, it should do to have #ifdef VNET_NFSD in prison_cleanup(). If it's to handle nfsd being dynamically loaded, the canonical way to handle it is via the OSD system, where the osd_jail_call(...PR_METHOD_REMOVE) would handle it. Or is there a third reason I don't know?
Aug 31 2022
Jul 3 2022
Jun 29 2022
May 16 2022
May 13 2022
In D35198#797902, @dchagin wrote:In D35198#797888, @jamie wrote:Wow, that has been there for an embarrassingly long time!
Well, it's not a bug)) because the rpr cannot be NULL AFAIR, or Im missed something?
Wow, that has been there for an embarrassingly long time!
Mar 28 2022
Mar 26 2022
Mar 12 2022
Mar 2 2022
Feb 27 2022
Feb 24 2022
Dec 19 2021
Dec 16 2021
In D33339#756945, @glebius wrote:@jamie I actually got one more question about this code. The code that checks for IP addresses clashing, in the old code under comment that starts "Check for conflicting IP addresses", in the new code separated into function prison_ip_conflict_check(), it would not allow to create a child that has IP address of a parent if parent has multiple addresses
...
So my patch doesn't change this behavior, but it seems counter-intuitive to me. And the comment actually says it is intended:If there is a duplicate on a jail with more than one IP stop checking and return error.
Why so?
Dec 15 2021
Dec 14 2021
I take it this is for what we're seeing in Bug 260335.
Dec 9 2021
Nov 11 2021
This presupposes that a jail that isn't marked to persist isn't going to stick around for some other reason. A jail could be started for example to start a long-running daemon, or to be a parent of other jails. Automatically going away when its task is done is a feature of such a jail.
Oct 7 2021
Sep 29 2021
Sep 4 2021
Jul 27 2021
I'm not thrilled at the redundant call to vfs_flagopt(), which shouldn't be necessary because kern_jail_set has already looked for allow.novmm and set the permission bit accordingly. But by the time vmmdev_prison_set() is called, the old value of the permission bit is forgotten. So you're left with
Jun 24 2021
Jun 18 2021
Apr 12 2021
Apr 11 2021
Apr 9 2021
Apr 8 2021
In D29659#665126, @me_igalic.co wrote:there are other candidates that return (0) or a single error that is always the same, but here we would need modifying the call-site :
- prison_check_af() 0/EAFNOSUPPORT
- prison_canseemount() 0/ENOENT
- prison_check() 0/ESRCH
Yeah, I'd been meaning to get around to that ;-).
Apr 4 2021
Mar 14 2021
This would work well with jexec -l, which is already somewhat like su -l but misses the parts you mention. In fact, I would recommend making clean (-l) the deciding factor instead of pwd (-u/U). And I don't see a reason why the same directory change shouldn't be done regardless of whether it's for a command or a shell.
Mar 12 2021
Mar 4 2021
Looks good - nothing to add.
Feb 27 2021
In D28952#648403, @kevans wrote:This is still a necessary change, it's just not the only one we need; I suspect both jail(8) and jexec(8) should try to switch to their root's id before running commands in a jail, so that administratively spawned stuff ends up with the jail's full mask.
In D28952#648403, @kevans wrote:I suspect both jail(8) and jexec(8) should try to switch to their root's id before running commands in a jail, so that administratively spawned stuff ends up with the jail's full mask.
(edit) e.g., https://people.freebsd.org/~kevans//jail-cpuset.diff which accomplishes this for jail(8) on start/stop.
In D28952#648302, @kevans wrote:In D28952#648283, @jamie wrote:But how about this: first at least try using the intersection of the current and jail sets (whether or not currently jailed), and only as a EDEADLK fallback punt to just using the jailed set.
Yeah, I think that makes sense -- we're talking about EDEADLK fallback if the priv is also set, so that it naturally gets cpuset down if it can?
Feb 26 2021
In D28952#648262, @jamie wrote:This might be a reason to keep PRIV_JAIL_CPUSET, and have it generally be available to virtual as well as real root.
In D28952#648258, @me_igalic.co wrote:how does this, or the current approach apply to jails in jails (which are under a specific CPU set?
Might PRIV_SCHED_CPUSET be sufficient for this? If a process has the ability to explicitly expand the current cpu list, it makes sense for it to be able to implicitly do so when attaching to a jail.
In D24570#616031, @netchild wrote:Would it make sense to be able to override the path (BTW: /etc/jail.conf.d would be my preference), in the sense of having it as a variable in /etc/defaults/rc.conf (would this help in the netboot case)?
Would it make sense to make this a list,, so that I could do e.g. jail_conf_dir="/etc/jail.conf.d /usr/local/etc/jail.conf.d"?
In D28150#647893, @kevans wrote:So, I'm going to ask a stupid question here; what all *actually* breaks if we end up with duplicate jids?
All previous work has been committed now (not without hiccups). This is the final-ish patch that only handles the main intent of the project.
Feb 25 2021
Sorry I took so long - I confused your note that it should be reverted with a note that it *had been* reverted.
Feb 23 2021
Feb 22 2021
Feb 21 2021
Feb 20 2021
Updated for cc7b73065302 and d4380c0cdd05.
Updated for cc7b73065302 and d4380c0cdd05.
Updated for cc7b73065302 and d4380c0cdd05.
Updated for cc7b73065302 and d4380c0cdd05.
Updated for cc7b73065302 and d4380c0cdd05.
Updated for cc7b73065302 and d4380c0cdd05.