Matt Dillon writes:
.....
> Idea #2: There are a number of sysctl's that effect jails globally,
> such as jail_sysvipc_allowed.
>
> Encapsulate these parameters in an internal named kernel structure and
> provide system calls to set and retrieve the parameters. e.g.
>
> int jail_param(int jailset, int cmd, int type, int value)
>
> cmd: JAIL_GET_PARAM or JAIL_SET_PARAM
> type: e.g. JAIL_TYPE_SYSVIPC_DISABLE
> value: e.g. 0 or 1 (if setting), unused if retrieving.
>
> Then allow the 'jailset' id to be specified in the jail() system call,
> allowing you to customize the sysctl parameters for any given jail.
> The least permissive of the global sysctl defaults and the jailset
> parameters would be used within the jail so you can still globally
> disable something in a running system.
And add jailset column to ps(1) (-o ?)
and programm, similar to kill(1) or killall(1) with jailset parameter.
And, of cause, jail(1) must print off jailset
> jail_param() would be disabled within a jail or when running at
> a securelevel other then -1. Combined with the first idea this
> would allow the system admin (outside the jail) to manipulate the
> jail parameters of jailed users running inside jails on the system.
--
@BABOLO http://links.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
