# devfs.conf not working in jail



## wonslung (Oct 29, 2013)

I have a system with ezjails installed and *I* have enabled the following:

```
export jail_squidjail_devfs_enable="YES"
export jail_squidjail_devfs_ruleset="devfsrules_jail"
```

In the jail, *I*'ve edited /etc/devfs.conf with the following:


```
#pf
own	pf 	root:100
perm	pf 	0640
```

I need these options in order for Squid to work as a transparent proxy. I can't find any information about this in my searches.

As a workaround *I*'m using crontab with an @reboot directive but this seems like the wrong way to do this. Any help would be greatly appreciated.


----------



## junovitch@ (Oct 29, 2013)

The default rules for jails, the one you are using, doesn't provide permissions to those.  You'll probably have to add an extra rule to append after the defaults in /etc/defaults/devfs.rules with something like this in the /etc/devfs.rules.  Note that this is the same as the default rule 4 for jails but is number 5 and has the pf unhide statement.  Then just update the ruleset for your jail with whatever you name it below.

```
[devfsrules_squidjail=5]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path pf unhide
add path zfs unhide
```


----------



## wonslung (Oct 30, 2013)

It looks like *I* already have that set in the host system:



```
[devfsrules_squidjail=4]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'pf' unhide
```


Also, to be clear, /dev/pf shows up inside the jail, it just doesn't have the proper group ownership.  Do *I* need to make the some other changes in the host system?

Currently, in the jail *I* have /etc/devfs.conf with the following directives:


```
#pf
own	pf 	root:100
perm	pf 	0640
```

I'm wondering if perhaps there is a setting in the host system which solves this. Like *I* said before, *I* can get the job done with a crontab but I know there has to be a better way. Thanks again.


----------



## wonslung (Oct 30, 2013)

I think *I* may have figured it out.  When *I* do the following command:


```
sysctl security | grep jail
```

I notice this:


```
security.jail.mount_devfs_allowed: 0
```

I'm going to try to change this and see if it works.

edit:

It didn't change anything.  I'm still having the same issue.


----------



## junovitch@ (Oct 30, 2013)

You need to make the /etc/devfs.conf changes on the host, not the jails.  The appropriate devfs rules are being assigned when you start the jail rather than from inside the jail.


Is this in your /etc/defaults/devfs.rules or your /etc/devfs.rules?

```
[devfsrules_squidjail=4]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'pf' unhide
```

See devfs() 

```
/etc/defaults/devfs.rules         Default devfs configuration file.
     /etc/devfs.rules                  Local devfs configuration file.  Rule-
                                       sets in here override those in
                                       /etc/defaults/devfs.rules with the same
                                       ruleset number, otherwise the two files
                                       are effectively merged.
```

Basically your example as rule 4 overrides those from the defaults.  Since you showed a non-default name this could cause problems.  You'll want to start from rule number 5 in /etc/devfs.rules (on the host, not the jail) for your local changes and leave the default alone.


----------



## wonslung (Oct 30, 2013)

I finally figured it out.


I needed to set it like this:


```
add path 'pf' unhide mode 0640 group squid unhide
```


----------



## SirDice (Oct 30, 2013)

Please note that unless you use VIMAGE you cannot control PF from within a jail.


----------



## wonslung (Oct 31, 2013)

SirDice said:
			
		

> Please note that unless you use VIMAGE you cannot control PF from within a jail.



All I know is that if I don't use /etc/devfs.rules and add this:


```
[devfsrules_squidjail=4]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'pf' unhide mode 0640 group squid unhide
```

Transparent Squid works inside of the jail.   

Without /dev/pf transparent Squid doesn't work.


----------



## wonslung (Nov 12, 2013)

I'm reopening this thread because I have the same problem in FreeBSD 10.  (I'm pretty sure it's due to a different reason, but the effect is the same)


I'm using ezjails.  My setup is the same as above, with a /etc/devfs.rules and the proper settings in my ezjails script. I found the following in UPDATING which I'm sure is causing my issue.



```
20131010:
        The rc.d/jail script has been updated to support jail(8)
        configuration file.  The "jail_<jname>_*" rc.conf(5) variables
        for per-jail configuration are automatically converted to
        /var/run/jail.<jname>.conf before the jail(8) utility is invoked.
        This is transparently backward compatible.  See below about some
        incompatibilities and rc.conf(5) manual page for more details.

        These variables are now deprecated in favor of jail(8) configuration
        file.  One can use "rc.d/jail config <jname>" command to generate
        a jail(8) configuration file in /var/run/jail.<jname>.conf without
        running the jail(8) utility.   The default pathname of the
        configuration file is /etc/jail.conf and can be specified by
        using $jail_conf or $jail_<jname>_conf variables.

        Please note that jail_devfs_ruleset accepts an integer at
        this moment.  Please consider to rewrite the ruleset name
        with an integer.
```


I'm not sure *I* understand it.  I want to continue using ezjails. devfs is being mounted but it's not applying the /etc/devfs.rules.

I've tried changing the name of the ruleset to devfsrules_jail1. This didn't work. I must have misunderstood the part of UPDATING about the ruleset needing an integer name. Any help would be appreciated.


----------



## wonslung (Nov 12, 2013)

I changed my ruleset to "200" which seems to have worked in the sense that the jail file SAYS it worked.

I see the following in /var/run/jail.squidjail.conf:


```
squidjail {
        host.hostname = "squidjail";
        path = "/usr/jails/squidjail";
        ip4.addr += "10.0.0.1/32";
        allow.raw_sockets = 0;
        exec.clean;
        exec.system_user = "root";
        exec.jail_user = "root";
        exec.start += "/bin/sh /etc/rc";
        exec.stop = "";
        exec.consolelog = "/var/log/jail_squidjail_console.log";
        mount.devfs;
        devfs_ruleset = "200";
        mount.fstab = "/etc/fstab.squidjail";
        mount.fdescfs;
        mount +=  "procfs /usr/jails/squidjail/proc procfs rw 0 0";
        allow.mount;
```


Showing devfs_ruleset is picking the proper rules, and that devfs is being mounted.

When *I* log into the jail, devfs is being mounted (which hasn't been the issue, it's been mounted the whole time)  but the rules still are not being applied.

Here's the section of the rules *I* want applied:


```
#
[200=4]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path zfs unhide
add path 'pf' unhide mode 0640 group 100 unhide
```

This used to be [devfsrules_jail=4] but I changed it to 200 due to what I read in UPDATING.


----------



## junovitch@ (Nov 14, 2013)

I haven't kept up on the changes in UPDATING but I think that is just referring the fact that you have to refer to it by rule number only, (4).  The rule number's name is a string, 200, and the integer referring to it is 4.  You can only use the rule number integer of 4 in your configuration.


----------



## wonslung (Nov 14, 2013)

It still doesn't seem to work when I change it to 4.


----------



## kaktus (Nov 18, 2013)

I came across that issue yesterday. The short story is: you need to add 
	
	



```
devfs_load_rulesets="YES"
```
 to /etc/rc.conf. The long story is on my blog: http://blog.rstack.cc/post/in_search_of_working_devfs_rules.


----------



## wonslung (Nov 20, 2013)

Nice find brother. This totally fixed my issue. No more using crontab with an @reboot rule.


----------

