On Sat, Aug 20, 2011 at 08:16:09AM -0400, Glen Barber wrote: > On 8/20/11 7:52 AM, Kostik Belousov wrote: > > On Sat, Aug 20, 2011 at 07:09:49AM -0400, Glen Barber wrote: > >> Hi, > >> > >> I would like to propose a change to bsd.port.mk which, similarly to > >> obtaining the OSVERSION, checks if the system on which a port is being > >> built is a jailed environment. > >> > >> This change can allow port maintainers to mark ports that do not run in > >> jailed environments as IGNORE, or adjust PKG_MESSAGE to inform the user > >> of special conditions or changes that will be needed to run a port from > >> within a jail. One particular example of the latter is > >> databases/postgresql*-server, where the user must enable > >> security.jail.sysvipc_allowed. I am sure this feature could expand to > >> other cases I have not considered yet, as well. > > > > I do not think this is good idea. The machine or environment where > > the port is built sometimes (or, in my setups, quite often) is not > > the same as where it is run. Your proposal gives a tool to tightly > > tie the ports to build environments, that is detrimental for some > > setups, and also diminish the value of packaging. IMHO. > > Hi Kostik, > > Thank you for the comments. > > I had neglected that some package building environments are jails with > the intent to install the packages on physical hardware or other > non-jailed environment, so this change would break those environments. > I had only tested the patches in a tinderbox environment. > > One thing I can think of off-hand to fix this in that case is setting a > local environment variable to disable a check for security.jail.jailed. > Would this be an ok solution for those cases? If not, I happily agree > that this change should not be made then. > > I have an updated patch to bsd.port.mk that looks for a local > environment variable, PKGJAIL - if it is set, then JAILED is unset. > Would this be acceptable? The change would require user to do a configuration for a thing that previously just worked. What is the point ?
Right solution for the ports you provided as examples in your original
mail, IMO, is to check and provide a diagnostic at runtime. In fact, I do
not see a need in any special diagnostic, e.g. the lack of /dev/pf or
lack of permissions to open /dev/pf is enough to refuse to work for
program that depends on ability to modify pf configuration.
Also, if pf(4) is implemented properly, then jails _can_ modify filter
rules if configured so by administrator. Similarly, postgres just work
in a properly configured jail.
>
> Regards,
>
> Glen
>
> --
> Glen Barber | g...@freebsd.org
> FreeBSD Documentation Project
> --- bsd.port.mk.orig 2011-08-12 12:39:23.000000000 -0400
> +++ bsd.port.mk 2011-08-20 08:07:12.656834897 -0400
> @@ -46,6 +46,7 @@
> # "FreeBSD," "NetBSD," or "OpenBSD" as
> appropriate.
> # OSREL - The release version (numeric) of the
> operating system.
> # OSVERSION - The value of __FreeBSD_version.
> +# JAILED - The system is a FreeBSD jail.
> #
> # This is the beginning of the list of all variables that need to be
> # defined in a port, listed in order that they should be included
> @@ -1196,6 +1197,15 @@
> .endif
> .endif
>
> +# Check if the system is a jail
> +.if !defined(JAILED)
> +. if !defined(PKGJAIL)
> +JAILED!= ${SYSCTL} -n security.jail.jailed
> +. else
> +JAILED=
> +. endif
> +.endif
> +
> MASTERDIR?= ${.CURDIR}
>
> .if ${MASTERDIR} != ${.CURDIR}
pgp0XtSfOp5tb.pgp
Description: PGP signature
