Symlinked cuaU* not accessible within jail

F

freebuser

Hi,

I have four USB serial adapters which I like to refer by USB0..3 under /dev.

Unfortunately when I create a symlink under /dev this is not available under the jail in which I have the web server require access to the cuaU* devices.

If I create the symlink under jail path /dev (from host) then it is accessible without any issues, but I like to automate this via devfs.rules.


Code: 
[devfsrules_unhide_myusb=18]
add path 'cuaU*' unhide
add path 'USB*' unhide


Code: 
[devfsrules_jail_web=6]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_unhide_myusb
add path zfs unhide
 
Interestingly when I tried kbd1 (symlink) and it was unhide inside jail. So what's wrong with the symlinks I made for cuaUx?

/dev/log didn't get unhide inside a jail either.
 
Yes I did, as I said the /dev/kbd works OK but not my symlink or the /dev/log get populated within the jail. No error when loading the rules.
 
What's devfs_ruleset set to in jail.conf? Also note that you need to restart devfs(8) after making the changes and you need to restart the jail in order for it to apply the new rules.
 
Rule set 6

Yes every time devfs and jail were restarted and as I said only the symlink to cuaUx is not populated.
 
Can someone please confirm if any symlink/s they created in the host under /dev actually get populated under jail /dev through devfs at least as a trial.

Thanks,
 
None of the symlinks you create on the host will be visible on the jails. The devfs(5) mounts under the jails are separate instances of the filesystem. Just think of how different mounts of the tmpfs(5) work, they don't share their contents between the different instances and that's exactly how devfs(5) works as well. The difference is of course that with tmpfs(5) you get an empty filesystem and with devfs(5) the filesystem is prepopulated with device nodes, directories and links according to the devfs.rules(5)rules.
 
kpa said:
None of the symlinks you create on the host will be visible on the jails. The devfs(5) mounts under the jails are separate instances of the filesystem. Just think of how different mounts of the tmpfs(5) work, they don't share their contents between the different instances and that's exactly how devfs(5) works as well. The difference is of course that with tmpfs(5) you get an empty filesystem and with devfs(5) the filesystem is prepopulated with device nodes, directories and links according to the devfs.rules(5)rules.
Click to expand...

Thanks kpa, that's what I thought too, but what I don't understand is if that is the case how come the fd/'s and kbd symlinks work under jail?
 
freebuser said:
Thanks kpa, that's what I thought too, but what I don't understand is if that is the case how come the fd/'s and kbd symlinks work under jail?
Click to expand...

They get created at the filesystem instance creation time using the currently active ruleset (set by the ruleset mount(8) option for devfs(5)) and are present when the devfs(5) filesystem is mounted under the jail's /dev directory. Then there's also the possibility of added and removed devices and those changes will be also reflected in the jail /dev if the ruleset allows those devices to be seen.
 
kpa said:
They get created at the filesystem instance creation time using the currently active ruleset (set by the ruleset mount(8) option for devfs(5)) and are present when the devfs(5) filesystem is mounted under the jail's /dev directory. Then there's also the possibility of added and removed devices and those changes will be also reflected in the jail /dev if the ruleset allows those devices to be seen.
Click to expand...
Ah ok.. Thanks.
 
You must log in or register to reply here.
Back
Top