Re: jail's periodic stuff

Hi Brian,

> Problem 1? "These scripts fail when you attempt to run then inside a jail(8)"
> 
> I don't see this as a problem, I see it as correct behaviour. You try to do
> something which you are not allowed to do, and the kernel prohibits it. The
> same would be true if you tried to run these scripts as a non-root user, for
> example.
> 
> I wouldn't expect to see magic in these scripts saying
> 
>     if [ `id -u` != 0 ]; then
>       exit 0
>     fi
> 
> so I don't see any need to add magic to exit early if the script is run in a
> jail.
>
> Problem 2? "These scripts are invoked by cron periodically in a default jail
> installation, and this causes spurious error mails to be sent out every day"
> 
> This I agree is undesirable behaviour, and it derives from the fact that a
> jail installation is just a normal FreeBSD installation, which expects that
> it needs to run periodic machine-level admin tasks when in fact it is
> running at the jail level where these tasks are inappropriate.
> 
> So for me the obvious solution is to make a jail installation slightly
> different from a normal installation, by installing /etc/periodic.conf which
> disables those tasks that send out spurious mails.
> 
> If you want to run the machine-level tasks only when cron is running outside
> a jail, without explicit configuration, then I'd suggest the place to put
> the magic is /etc/defaults/periodic.conf (which is, after all, just a shell
> script)
> 
>     if [ `sysctl -n security.jail.jailed` == 0 ]; then
>       not_jailed="YES"
>     else
>       not_jailed="NO"
>     fi
> 
>     ...
> 
>     # 600.ip6fwdenied
>     daily_status_security_ip6fwdenied_enable=not_jailed
> 
>     # 610.ipf6denied
>     daily_status_security_ipf6denied_enable=not_jailed
> 
> This seems cleaner to me, as it still allows you to override these policies
> (even if that's not currently a useful thing to do)

Actually, I was thinking of the rc.d scripts.  In the maneer of periodic
scripts, they are not intended to be executed by a normal user (as all
scripts under /etc), so they don't need this kind of magic.  I agree
with you on this point.

Nonetheless rc.d scripts does have a ``nojail'' keyword, but these are
run through the rc(8) framework, which is not the case of periodic
scripts.  Therefore we can't easily use such a keyword.
There are two options offered to us in my point of view :

    o add the following test to each script that can't be run in
      a jail environnement :
      % if [ `sysctl -n security.jail.jailed` -eq 1 ]
      % then
      %		exit 0
      % fi

    o modify periodic(8) in order to handle such a keyword.

In my opinion, given that there is only a few scripts that should be
avoided inside a jail, the second solution is a little bit overkill,
but I wanted to be sure of this, thus my question here.

But the solution you proposed below is quite attractive because this is
little intrusive and doesn't require code duplication across periodic
scripts.  The attached patch modifies etc/defaults/periodic.conf and
implements this.

Note that I'm still not sure about these scripts :
	400.status-disks
	405.status-ata-raid
	420.status-network
For instance, 420 uses ``netstat -in''.  It will not be able to run
inside a jail, unless /dev/mem is available (I'm not sure this is
still the case with rwatson_at_ recent changes), which is, while still
possible, very unlikely.  I would like to hear some advice of wise
people about this.

Thank you.
Best regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >