devd in jail

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

devd in jail

Giulio Ferro
Hello all,

Setup :  11.1-STABLE FreeBSD 11.1-STABLE #0 r321925M amd64


I'm trying to create a fully virtualized desktop enviroment in a jail by
means of installing there
a xrdp-devel server + Xorg installation (xorg + xorgrdp).

Everything seems to work until the moment when the X server actually
tries to come up (after I choose session=xorg, username + password)
In the X logs in the jail, in fact, I have this error:

...
[  9768.824] (EE) config/devd: fail to connect to devd
[  9768.824] [config] failed to initialise devd


I've checked on the host machine, and I don't have that error as
everything works fine there...

In my jail, I've setup the devfs like this (/etc/jail.conf in the host):

---
exec.start="/bin/sh /etc/rc";
exec.stop="/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset=1;

path="/usr/home/jail/$name";

myjail {
         host.hostname="myjail.me.com";
         vnet;
         vnet.interface = epair0b, epair1b;
         persist;
}
---


and in the /etc/devfs.conf everythink is commented out.

In the /dev directory in the jail, I get both the devctl and devctl2
devices.

As the devd demon is not running in the jail, I've tried adding
devd_enable="YES"

in the rc.conf (jail), but when I try to start it, I get:

# /etc/rc.d/devd start
Starting devd.
devd: Can't open devctl device /dev/devctl: Device busy
/etc/rc.d/devd: WARNING: failed to start devd


Do you know if I'm doing something wrong, or there's a proper way to
have devd running in the jail?

I've thought that maybe I should use the devtcl2 device, as the devctl
is used by the host,
but I don't know how to specify that to devd...

Thanks in advance for your help.

Giulio
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Alan Somers-2
On Wed, Aug 9, 2017 at 12:47 PM, Giulio Ferro <[hidden email]> wrote:

> Hello all,
>
> Setup :  11.1-STABLE FreeBSD 11.1-STABLE #0 r321925M amd64
>
>
> I'm trying to create a fully virtualized desktop enviroment in a jail by
> means of installing there
> a xrdp-devel server + Xorg installation (xorg + xorgrdp).
>
> Everything seems to work until the moment when the X server actually tries
> to come up (after I choose session=xorg, username + password)
> In the X logs in the jail, in fact, I have this error:
>
> ...
> [  9768.824] (EE) config/devd: fail to connect to devd
> [  9768.824] [config] failed to initialise devd
>
>
> I've checked on the host machine, and I don't have that error as everything
> works fine there...
>
> In my jail, I've setup the devfs like this (/etc/jail.conf in the host):
>
> ---
> exec.start="/bin/sh /etc/rc";
> exec.stop="/bin/sh /etc/rc.shutdown";
> exec.clean;
> mount.devfs;
> devfs_ruleset=1;
>
> path="/usr/home/jail/$name";
>
> myjail {
>         host.hostname="myjail.me.com";
>         vnet;
>         vnet.interface = epair0b, epair1b;
>         persist;
> }
> ---
>
>
> and in the /etc/devfs.conf everythink is commented out.
>
> In the /dev directory in the jail, I get both the devctl and devctl2
> devices.
>
> As the devd demon is not running in the jail, I've tried adding
> devd_enable="YES"
>
> in the rc.conf (jail), but when I try to start it, I get:
>
> # /etc/rc.d/devd start
> Starting devd.
> devd: Can't open devctl device /dev/devctl: Device busy
> /etc/rc.d/devd: WARNING: failed to start devd
>
>
> Do you know if I'm doing something wrong, or there's a proper way to have
> devd running in the jail?
>
> I've thought that maybe I should use the devtcl2 device, as the devctl is
> used by the host,
> but I don't know how to specify that to devd...
>
> Thanks in advance for your help.
>
> Giulio

Unfortunately, you're not going to be able to run devd(8) in the jail.
/dev/devctl can be opened by only one reader at a time, and that
reader is always devd(8).  /dev/devctl2 is actually a completely
different device with a totally different interface.  Apologies for
the confusing names.  But you may not need to run a totally separate
instance of devd.  The X server is probably trying to open either
/var/run/devd.pipe or /var/run/devd.seqpacket.pipe.  ktrace would tell
you which.  If you can bridge those sockets into the jail, then X
would probably run.

-Alan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Alexander Leidinger

Quoting Alan Somers <[hidden email]> (from Wed, 9 Aug 2017  
13:14:20 -0600):

> On Wed, Aug 9, 2017 at 12:47 PM, Giulio Ferro <[hidden email]> wrote:
>> Hello all,
>>
>> Setup :  11.1-STABLE FreeBSD 11.1-STABLE #0 r321925M amd64
>>
>>
>> I'm trying to create a fully virtualized desktop enviroment in a jail by
>> means of installing there
>> a xrdp-devel server + Xorg installation (xorg + xorgrdp).
>>
>> Everything seems to work until the moment when the X server actually tries
>> to come up (after I choose session=xorg, username + password)
>> In the X logs in the jail, in fact, I have this error:
>>
>> ...
>> [  9768.824] (EE) config/devd: fail to connect to devd
>> [  9768.824] [config] failed to initialise devd
>>
>>
>> I've checked on the host machine, and I don't have that error as everything
>> works fine there...
>>
>> In my jail, I've setup the devfs like this (/etc/jail.conf in the host):
>>
>> ---
>> exec.start="/bin/sh /etc/rc";
>> exec.stop="/bin/sh /etc/rc.shutdown";
>> exec.clean;
>> mount.devfs;
>> devfs_ruleset=1;
>>
>> path="/usr/home/jail/$name";
>>
>> myjail {
>>         host.hostname="myjail.me.com";
>>         vnet;
>>         vnet.interface = epair0b, epair1b;
>>         persist;
>> }
>> ---
>>
>>
>> and in the /etc/devfs.conf everythink is commented out.
>>
>> In the /dev directory in the jail, I get both the devctl and devctl2
>> devices.
>>
>> As the devd demon is not running in the jail, I've tried adding
>> devd_enable="YES"
>>
>> in the rc.conf (jail), but when I try to start it, I get:
>>
>> # /etc/rc.d/devd start
>> Starting devd.
>> devd: Can't open devctl device /dev/devctl: Device busy
>> /etc/rc.d/devd: WARNING: failed to start devd
>>
>>
>> Do you know if I'm doing something wrong, or there's a proper way to have
>> devd running in the jail?
>>
>> I've thought that maybe I should use the devtcl2 device, as the devctl is
>> used by the host,
>> but I don't know how to specify that to devd...
>>
>> Thanks in advance for your help.
>>
>> Giulio
>
> Unfortunately, you're not going to be able to run devd(8) in the jail.
> /dev/devctl can be opened by only one reader at a time, and that
> reader is always devd(8).  /dev/devctl2 is actually a completely
> different device with a totally different interface.  Apologies for
> the confusing names.  But you may not need to run a totally separate
> instance of devd.  The X server is probably trying to open either
> /var/run/devd.pipe or /var/run/devd.seqpacket.pipe.  ktrace would tell
> you which.  If you can bridge those sockets into the jail, then X
> would probably run.
Apart from using an explicit config of devices instead of HAL / devd,  
if this is a X server connecting to a graphics card (instead of just a  
remote accessible framebuffer), the X-in-a-jail patches are needed, as  
the X server needs access to /dev/(k)mem and /dev/io (and /dev/drm).

ATTENTION: doing this compromises the complete security of the entire  
machine. The jail with the X-server can then access the entire memory  
of the machine, this means circumventing any kernel-level security  
protection / jail restrictions.

Using the PR_ALLOW_* flags from current in 11.1 is ok (sys/sys/jail.h):
---snip---
/* Flags for pr_allow */
#define PR_ALLOW_SET_HOSTNAME           0x00000001
#define PR_ALLOW_SYSVIPC                0x00000002
#define PR_ALLOW_RAW_SOCKETS            0x00000004
#define PR_ALLOW_CHFLAGS                0x00000008
#define PR_ALLOW_MOUNT                  0x00000010
#define PR_ALLOW_QUOTAS                 0x00000020
#define PR_ALLOW_SOCKET_AF              0x00000040
#define PR_ALLOW_MOUNT_DEVFS            0x00000080
#define PR_ALLOW_MOUNT_NULLFS           0x00000100
#define PR_ALLOW_MOUNT_ZFS              0x00000200
#define PR_ALLOW_MOUNT_PROCFS           0x00000400
#define PR_ALLOW_MOUNT_TMPFS            0x00000800
#define PR_ALLOW_MOUNT_FDESCFS          0x00001000
#define PR_ALLOW_MOUNT_LINPROCFS        0x00002000
#define PR_ALLOW_MOUNT_LINSYSFS         0x00004000
#define PR_ALLOW_RESERVED_PORTS         0x00008000
#define PR_ALLOW_KMEM_ACCESS            0x00010000      /* reserved,  
not used yet */
#define PR_ALLOW_ALL                    0x0001ffff
---snip---

Then kern_jail.c needs a little patch:
---snip---
Index: sys/kern/kern_jail.c
===================================================================
--- sys/kern/kern_jail.c    (revision 321365)
+++ sys/kern/kern_jail.c    (working copy)
@@ -200,6 +200,7 @@
         "allow.mount.linprocfs",
         "allow.mount.linsysfs",
         "allow.reserved_ports",
+       "allow.kmem_access",
  };
  const size_t pr_allow_names_size = sizeof(pr_allow_names);

@@ -220,6 +221,7 @@
         "allow.mount.nolinprocfs",
         "allow.mount.nolinsysfs",
         "allow.noreserved_ports",
+       "allow.nokmem_access",
  };
  const size_t pr_allow_nonames_size = sizeof(pr_allow_nonames);

@@ -3344,6 +3346,27 @@
                 return (0);

                 /*
+                * Allow access to /dev/io in a jail if the non-jailed admin
+                * requests this and if /dev/io exists in the jail. This
+                * allows Xorg to probe a card.
+                */
+       case PRIV_IO:
+               if (cred->cr_prison->pr_allow & PR_ALLOW_KMEM_ACCESS)
+                       return (0);
+               else
+                       return (EPERM);
+
+               /*
+                * Allow low level access to KMEM-like devices (e.g. to
+                * allow Xorg to use DRI).
+                */
+       case PRIV_KMEM_WRITE:
+               if (cred->cr_prison->pr_allow & PR_ALLOW_KMEM_ACCESS)
+                       return (0);
+               else
+                       return (EPERM);
+
+               /*
                  * Allow jailed root to set loginclass.
                  */
         case PRIV_PROC_SETLOGINCLASS:
---snip---

For 11.1 one little change is needed to get DRM access... see  
https://svnweb.freebsd.org/changeset/base/320827

The jail then needs to be started with "allow.kmem_access" and  
appropriate devfs rules (the jail needs rule 15 or 18, you may want to  
give more or less access, depending on your needs, review with care):
---snip---
[devfsrules_unhide_audio=5]
add path 'audio*' unhide
add path 'dsp*' unhide
add path midistat unhide
add path 'mixer*' unhide
add path 'music*' unhide
add path 'sequencer*' unhide
add path sndstat unhide
add path speaker unhide

[devfsrules_unhide_input=7]
add path 'atkbd*' unhide
add path 'kbd*' unhide
add path 'joy*' unhide
add path 'psm*' unhide
add path sysmouse unhide
add path 'ukbd*' unhide
add path 'ums*' unhide

[devfsrules_unhide_xorg=8]
add path agpgart unhide
#add path console unhide
add path dri unhide
add path 'dri/card*' unhide
add path nvidiactl unhide
add path 'nvidia*' unhide
add path io unhide
add path mem unhide
add path pci unhide
add path tty unhide
add path ttyv0 unhide
add path ttyv1 unhide
add path ttyv8 unhide

[devfsrules_unhide_kmem=11]
add path kmem unhide

[devfsrules_unhide_zfs=12]
add path zfs unhide

#
# This allows to run a desktop system in a jail.  Think about what you want to
# achieve before you use this, it opens up the entire machine to access from
# this jail to any sophisticated program.
#
[devfsrules_jail_desktop=15]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_unhide_audio
add include $devfsrules_unhide_input
add include $devfsrules_unhide_xorg
add include $devfsrules_unhide_kmem

[devfsrules_jail_desktop_withzfs=18]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_unhide_audio
add include $devfsrules_unhide_input
add include $devfsrules_unhide_xorg
add include $devfsrules_unhide_kmem
add include $devfsrules_unhide_zfs
---snip---

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
In reply to this post by Alan Somers-2
On 09/08/2017 21:14, Alan Somers wrote:

> On Wed, Aug 9, 2017 at 12:47 PM, Giulio Ferro <[hidden email]> wrote:
>> Hello all,
>>
>> Setup :  11.1-STABLE FreeBSD 11.1-STABLE #0 r321925M amd64
>>
>>
>> I'm trying to create a fully virtualized desktop enviroment in a jail by
>> means of installing there
>> a xrdp-devel server + Xorg installation (xorg + xorgrdp).
>>
>> Everything seems to work until the moment when the X server actually tries
>> to come up (after I choose session=xorg, username + password)
>> In the X logs in the jail, in fact, I have this error:
>>
>> ...
>> [  9768.824] (EE) config/devd: fail to connect to devd
>> [  9768.824] [config] failed to initialise devd
>>
>>
>> I've checked on the host machine, and I don't have that error as everything
>> works fine there...
>>
>> In my jail, I've setup the devfs like this (/etc/jail.conf in the host):
>>
>> ---
>> exec.start="/bin/sh /etc/rc";
>> exec.stop="/bin/sh /etc/rc.shutdown";
>> exec.clean;
>> mount.devfs;
>> devfs_ruleset=1;
>>
>> path="/usr/home/jail/$name";
>>
>> myjail {
>>          host.hostname="myjail.me.com";
>>          vnet;
>>          vnet.interface = epair0b, epair1b;
>>          persist;
>> }
>> ---
>>
>>
>> and in the /etc/devfs.conf everythink is commented out.
>>
>> In the /dev directory in the jail, I get both the devctl and devctl2
>> devices.
>>
>> As the devd demon is not running in the jail, I've tried adding
>> devd_enable="YES"
>>
>> in the rc.conf (jail), but when I try to start it, I get:
>>
>> # /etc/rc.d/devd start
>> Starting devd.
>> devd: Can't open devctl device /dev/devctl: Device busy
>> /etc/rc.d/devd: WARNING: failed to start devd
>>
>>
>> Do you know if I'm doing something wrong, or there's a proper way to have
>> devd running in the jail?
>>
>> I've thought that maybe I should use the devtcl2 device, as the devctl is
>> used by the host,
>> but I don't know how to specify that to devd...
>>
>> Thanks in advance for your help.
>>
>> Giulio
> Unfortunately, you're not going to be able to run devd(8) in the jail.
> /dev/devctl can be opened by only one reader at a time, and that
> reader is always devd(8).  /dev/devctl2 is actually a completely
> different device with a totally different interface.  Apologies for
> the confusing names.  But you may not need to run a totally separate
> instance of devd.  The X server is probably trying to open either
> /var/run/devd.pipe or /var/run/devd.seqpacket.pipe.  ktrace would tell
> you which.  If you can bridge those sockets into the jail, then X
> would probably run.
>
> -Alan
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"


Hi Alan,

sorry for the late feedback and thanks for your advice.

Unfortunately I haven't found a way to bridge (as you say) the relevant
pipe files to the jail.


I've tried to mount_nullfs the host /var/run to the jail /var/run, but
with tragic results, as the jail deletes

the /var/run content when it starts up.


Do you have some better way to do that? I ask because this may be more
convenient venue compared  to apply the patches,

and more portable in case of updates, etc...


Thanks


Giulio


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
In reply to this post by Alexander Leidinger
On 10/08/2017 22:54, Alexander Leidinger wrote:

>
> Quoting Alan Somers <[hidden email]> (from Wed, 9 Aug 2017
> 13:14:20 -0600):
>
>> On Wed, Aug 9, 2017 at 12:47 PM, Giulio Ferro <[hidden email]>
>> wrote:
>>> Hello all,
>>>
>>> Setup :  11.1-STABLE FreeBSD 11.1-STABLE #0 r321925M amd64
>>>
>>>
>>> I'm trying to create a fully virtualized desktop enviroment in a
>>> jail by
>>> means of installing there
>>> a xrdp-devel server + Xorg installation (xorg + xorgrdp).
>>>
>>> Everything seems to work until the moment when the X server actually
>>> tries
>>> to come up (after I choose session=xorg, username + password)
>>> In the X logs in the jail, in fact, I have this error:
>>>
>>> ...
>>> [  9768.824] (EE) config/devd: fail to connect to devd
>>> [  9768.824] [config] failed to initialise devd
>>>
>>>
>>> I've checked on the host machine, and I don't have that error as
>>> everything
>>> works fine there...
>>>
>>> In my jail, I've setup the devfs like this (/etc/jail.conf in the
>>> host):
>>>
>>> ---
>>> exec.start="/bin/sh /etc/rc";
>>> exec.stop="/bin/sh /etc/rc.shutdown";
>>> exec.clean;
>>> mount.devfs;
>>> devfs_ruleset=1;
>>>
>>> path="/usr/home/jail/$name";
>>>
>>> myjail {
>>>         host.hostname="myjail.me.com";
>>>         vnet;
>>>         vnet.interface = epair0b, epair1b;
>>>         persist;
>>> }
>>> ---
>>>
>>>
>>> and in the /etc/devfs.conf everythink is commented out.
>>>
>>> In the /dev directory in the jail, I get both the devctl and devctl2
>>> devices.
>>>
>>> As the devd demon is not running in the jail, I've tried adding
>>> devd_enable="YES"
>>>
>>> in the rc.conf (jail), but when I try to start it, I get:
>>>
>>> # /etc/rc.d/devd start
>>> Starting devd.
>>> devd: Can't open devctl device /dev/devctl: Device busy
>>> /etc/rc.d/devd: WARNING: failed to start devd
>>>
>>>
>>> Do you know if I'm doing something wrong, or there's a proper way to
>>> have
>>> devd running in the jail?
>>>
>>> I've thought that maybe I should use the devtcl2 device, as the
>>> devctl is
>>> used by the host,
>>> but I don't know how to specify that to devd...
>>>
>>> Thanks in advance for your help.
>>>
>>> Giulio
>>
>> Unfortunately, you're not going to be able to run devd(8) in the jail.
>> /dev/devctl can be opened by only one reader at a time, and that
>> reader is always devd(8).  /dev/devctl2 is actually a completely
>> different device with a totally different interface.  Apologies for
>> the confusing names.  But you may not need to run a totally separate
>> instance of devd.  The X server is probably trying to open either
>> /var/run/devd.pipe or /var/run/devd.seqpacket.pipe.  ktrace would tell
>> you which.  If you can bridge those sockets into the jail, then X
>> would probably run.
>
> Apart from using an explicit config of devices instead of HAL / devd,
> if this is a X server connecting to a graphics card (instead of just a
> remote accessible framebuffer), the X-in-a-jail patches are needed, as
> the X server needs access to /dev/(k)mem and /dev/io (and /dev/drm).
>

Hi Alexander,

as I said, I don't actually need to connect to any device, as this Xorg
server in the jail only uses xrdp as backend.




> ATTENTION: doing this compromises the complete security of the entire
> machine. The jail with the X-server can then access the entire memory
> of the machine, this means circumventing any kernel-level security
> protection / jail restrictions.

Can you confirm that the following patch is everything I need to run
Xorg in a jail in a 11.1 stable system?

>
> Using the PR_ALLOW_* flags from current in 11.1 is ok (sys/sys/jail.h):
> ---snip---
> /* Flags for pr_allow */
> #define PR_ALLOW_SET_HOSTNAME           0x00000001
> #define PR_ALLOW_SYSVIPC                0x00000002
> #define PR_ALLOW_RAW_SOCKETS            0x00000004
> #define PR_ALLOW_CHFLAGS                0x00000008
> #define PR_ALLOW_MOUNT                  0x00000010
> #define PR_ALLOW_QUOTAS                 0x00000020
> #define PR_ALLOW_SOCKET_AF              0x00000040
> #define PR_ALLOW_MOUNT_DEVFS            0x00000080
> #define PR_ALLOW_MOUNT_NULLFS           0x00000100
> #define PR_ALLOW_MOUNT_ZFS              0x00000200
> #define PR_ALLOW_MOUNT_PROCFS           0x00000400
> #define PR_ALLOW_MOUNT_TMPFS            0x00000800
> #define PR_ALLOW_MOUNT_FDESCFS          0x00001000
> #define PR_ALLOW_MOUNT_LINPROCFS        0x00002000
> #define PR_ALLOW_MOUNT_LINSYSFS         0x00004000
> #define PR_ALLOW_RESERVED_PORTS         0x00008000
> #define PR_ALLOW_KMEM_ACCESS            0x00010000      /* reserved,
> not used yet */
> #define PR_ALLOW_ALL                    0x0001ffff
> ---snip---
>
> Then kern_jail.c needs a little patch:
> ---snip---
> Index: sys/kern/kern_jail.c
> ===================================================================
> --- sys/kern/kern_jail.c    (revision 321365)
> +++ sys/kern/kern_jail.c    (working copy)
> @@ -200,6 +200,7 @@
>         "allow.mount.linprocfs",
>         "allow.mount.linsysfs",
>         "allow.reserved_ports",
> +       "allow.kmem_access",
>  };
>  const size_t pr_allow_names_size = sizeof(pr_allow_names);
>
> @@ -220,6 +221,7 @@
>         "allow.mount.nolinprocfs",
>         "allow.mount.nolinsysfs",
>         "allow.noreserved_ports",
> +       "allow.nokmem_access",
>  };
>  const size_t pr_allow_nonames_size = sizeof(pr_allow_nonames);
>
> @@ -3344,6 +3346,27 @@
>                 return (0);
>
>                 /*
> +                * Allow access to /dev/io in a jail if the non-jailed
> admin
> +                * requests this and if /dev/io exists in the jail. This
> +                * allows Xorg to probe a card.
> +                */
> +       case PRIV_IO:
> +               if (cred->cr_prison->pr_allow & PR_ALLOW_KMEM_ACCESS)
> +                       return (0);
> +               else
> +                       return (EPERM);
> +
> +               /*
> +                * Allow low level access to KMEM-like devices (e.g. to
> +                * allow Xorg to use DRI).
> +                */
> +       case PRIV_KMEM_WRITE:
> +               if (cred->cr_prison->pr_allow & PR_ALLOW_KMEM_ACCESS)
> +                       return (0);
> +               else
> +                       return (EPERM);
> +
> +               /*
>                  * Allow jailed root to set loginclass.
>                  */
>         case PRIV_PROC_SETLOGINCLASS:
> ---snip---
>
> For 11.1 one little change is needed to get DRM access... see
> https://svnweb.freebsd.org/changeset/base/320827
>
> The jail then needs to be started with "allow.kmem_access" and
> appropriate devfs rules (the jail needs rule 15 or 18, you may want to
> give more or less access, depending on your needs, review with care):
> ---snip---
> [devfsrules_unhide_audio=5]
> add path 'audio*' unhide
> add path 'dsp*' unhide
> add path midistat unhide
> add path 'mixer*' unhide
> add path 'music*' unhide
> add path 'sequencer*' unhide
> add path sndstat unhide
> add path speaker unhide
>
> [devfsrules_unhide_input=7]
> add path 'atkbd*' unhide
> add path 'kbd*' unhide
> add path 'joy*' unhide
> add path 'psm*' unhide
> add path sysmouse unhide
> add path 'ukbd*' unhide
> add path 'ums*' unhide
>
> [devfsrules_unhide_xorg=8]
> add path agpgart unhide
> #add path console unhide
> add path dri unhide
> add path 'dri/card*' unhide
> add path nvidiactl unhide
> add path 'nvidia*' unhide
> add path io unhide
> add path mem unhide
> add path pci unhide
> add path tty unhide
> add path ttyv0 unhide
> add path ttyv1 unhide
> add path ttyv8 unhide
>
> [devfsrules_unhide_kmem=11]
> add path kmem unhide
>
> [devfsrules_unhide_zfs=12]
> add path zfs unhide
>
> #
> # This allows to run a desktop system in a jail.  Think about what you
> want to
> # achieve before you use this, it opens up the entire machine to
> access from
> # this jail to any sophisticated program.
> #
> [devfsrules_jail_desktop=15]
> add include $devfsrules_hide_all
> add include $devfsrules_unhide_basic
> add include $devfsrules_unhide_login
> add include $devfsrules_unhide_audio
> add include $devfsrules_unhide_input
> add include $devfsrules_unhide_xorg
> add include $devfsrules_unhide_kmem
>
> [devfsrules_jail_desktop_withzfs=18]
> add include $devfsrules_hide_all
> add include $devfsrules_unhide_basic
> add include $devfsrules_unhide_login
> add include $devfsrules_unhide_audio
> add include $devfsrules_unhide_input
> add include $devfsrules_unhide_xorg
> add include $devfsrules_unhide_kmem
> add include $devfsrules_unhide_zfs
> ---snip---
>
> Bye,
> Alexander.
>

Thanks


Giulio

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
In reply to this post by Alexander Leidinger
Hi Alexander,

This set of patches doesn't seem to apply to 11.1 stable, am I right?


> Il giorno 10 ago 2017, alle ore 22:54, Alexander Leidinger <[hidden email]> ha scritto:
>
>
> Quoting Alan Somers <[hidden email]> (from Wed, 9 Aug 2017 13:14:20 -0600):
>
>>> On Wed, Aug 9, 2017 at 12:47 PM, Giulio Ferro <[hidden email]> wrote:
>>> Hello all,
>>>
>>> Setup :  11.1-STABLE FreeBSD 11.1-STABLE #0 r321925M amd64
>>>
>>>
>>> I'm trying to create a fully virtualized desktop enviroment in a jail by
>>> means of installing there
>>> a xrdp-devel server + Xorg installation (xorg + xorgrdp).
>>>
>>> Everything seems to work until the moment when the X server actually tries
>>> to come up (after I choose session=xorg, username + password)
>>> In the X logs in the jail, in fact, I have this error:
>>>
>>> ...
>>> [  9768.824] (EE) config/devd: fail to connect to devd
>>> [  9768.824] [config] failed to initialise devd
>>>
>>>
>>> I've checked on the host machine, and I don't have that error as everything
>>> works fine there...
>>>
>>> In my jail, I've setup the devfs like this (/etc/jail.conf in the host):
>>>
>>> ---
>>> exec.start="/bin/sh /etc/rc";
>>> exec.stop="/bin/sh /etc/rc.shutdown";
>>> exec.clean;
>>> mount.devfs;
>>> devfs_ruleset=1;
>>>
>>> path="/usr/home/jail/$name";
>>>
>>> myjail {
>>>        host.hostname="myjail.me.com";
>>>        vnet;
>>>        vnet.interface = epair0b, epair1b;
>>>        persist;
>>> }
>>> ---
>>>
>>>
>>> and in the /etc/devfs.conf everythink is commented out.
>>>
>>> In the /dev directory in the jail, I get both the devctl and devctl2
>>> devices.
>>>
>>> As the devd demon is not running in the jail, I've tried adding
>>> devd_enable="YES"
>>>
>>> in the rc.conf (jail), but when I try to start it, I get:
>>>
>>> # /etc/rc.d/devd start
>>> Starting devd.
>>> devd: Can't open devctl device /dev/devctl: Device busy
>>> /etc/rc.d/devd: WARNING: failed to start devd
>>>
>>>
>>> Do you know if I'm doing something wrong, or there's a proper way to have
>>> devd running in the jail?
>>>
>>> I've thought that maybe I should use the devtcl2 device, as the devctl is
>>> used by the host,
>>> but I don't know how to specify that to devd...
>>>
>>> Thanks in advance for your help.
>>>
>>> Giulio
>>
>> Unfortunately, you're not going to be able to run devd(8) in the jail.
>> /dev/devctl can be opened by only one reader at a time, and that
>> reader is always devd(8).  /dev/devctl2 is actually a completely
>> different device with a totally different interface.  Apologies for
>> the confusing names.  But you may not need to run a totally separate
>> instance of devd.  The X server is probably trying to open either
>> /var/run/devd.pipe or /var/run/devd.seqpacket.pipe.  ktrace would tell
>> you which.  If you can bridge those sockets into the jail, then X
>> would probably run.
>
> Apart from using an explicit config of devices instead of HAL / devd, if this is a X server connecting to a graphics card (instead of just a remote accessible framebuffer), the X-in-a-jail patches are needed, as the X server needs access to /dev/(k)mem and /dev/io (and /dev/drm).
>
> ATTENTION: doing this compromises the complete security of the entire machine. The jail with the X-server can then access the entire memory of the machine, this means circumventing any kernel-level security protection / jail restrictions.
>
> Using the PR_ALLOW_* flags from current in 11.1 is ok (sys/sys/jail.h):
> ---snip---
> /* Flags for pr_allow */
> #define PR_ALLOW_SET_HOSTNAME           0x00000001
> #define PR_ALLOW_SYSVIPC                0x00000002
> #define PR_ALLOW_RAW_SOCKETS            0x00000004
> #define PR_ALLOW_CHFLAGS                0x00000008
> #define PR_ALLOW_MOUNT                  0x00000010
> #define PR_ALLOW_QUOTAS                 0x00000020
> #define PR_ALLOW_SOCKET_AF              0x00000040
> #define PR_ALLOW_MOUNT_DEVFS            0x00000080
> #define PR_ALLOW_MOUNT_NULLFS           0x00000100
> #define PR_ALLOW_MOUNT_ZFS              0x00000200
> #define PR_ALLOW_MOUNT_PROCFS           0x00000400
> #define PR_ALLOW_MOUNT_TMPFS            0x00000800
> #define PR_ALLOW_MOUNT_FDESCFS          0x00001000
> #define PR_ALLOW_MOUNT_LINPROCFS        0x00002000
> #define PR_ALLOW_MOUNT_LINSYSFS         0x00004000
> #define PR_ALLOW_RESERVED_PORTS         0x00008000
> #define PR_ALLOW_KMEM_ACCESS            0x00010000      /* reserved, not used yet */
> #define PR_ALLOW_ALL                    0x0001ffff
> ---snip---
>
> Then kern_jail.c needs a little patch:
> ---snip---
> Index: sys/kern/kern_jail.c
> ===================================================================
> --- sys/kern/kern_jail.c    (revision 321365)
> +++ sys/kern/kern_jail.c    (working copy)
> @@ -200,6 +200,7 @@
>        "allow.mount.linprocfs",
>        "allow.mount.linsysfs",
>        "allow.reserved_ports",
> +       "allow.kmem_access",
> };
> const size_t pr_allow_names_size = sizeof(pr_allow_names);
>
> @@ -220,6 +221,7 @@
>        "allow.mount.nolinprocfs",
>        "allow.mount.nolinsysfs",
>        "allow.noreserved_ports",
> +       "allow.nokmem_access",
> };
> const size_t pr_allow_nonames_size = sizeof(pr_allow_nonames);
>
> @@ -3344,6 +3346,27 @@
>                return (0);
>
>                /*
> +                * Allow access to /dev/io in a jail if the non-jailed admin
> +                * requests this and if /dev/io exists in the jail. This
> +                * allows Xorg to probe a card.
> +                */
> +       case PRIV_IO:
> +               if (cred->cr_prison->pr_allow & PR_ALLOW_KMEM_ACCESS)
> +                       return (0);
> +               else
> +                       return (EPERM);
> +
> +               /*
> +                * Allow low level access to KMEM-like devices (e.g. to
> +                * allow Xorg to use DRI).
> +                */
> +       case PRIV_KMEM_WRITE:
> +               if (cred->cr_prison->pr_allow & PR_ALLOW_KMEM_ACCESS)
> +                       return (0);
> +               else
> +                       return (EPERM);
> +
> +               /*
>                 * Allow jailed root to set loginclass.
>                 */
>        case PRIV_PROC_SETLOGINCLASS:
> ---snip---
>
> For 11.1 one little change is needed to get DRM access... see https://svnweb.freebsd.org/changeset/base/320827
>
> The jail then needs to be started with "allow.kmem_access" and appropriate devfs rules (the jail needs rule 15 or 18, you may want to give more or less access, depending on your needs, review with care):
> ---snip---
> [devfsrules_unhide_audio=5]
> add path 'audio*' unhide
> add path 'dsp*' unhide
> add path midistat unhide
> add path 'mixer*' unhide
> add path 'music*' unhide
> add path 'sequencer*' unhide
> add path sndstat unhide
> add path speaker unhide
>
> [devfsrules_unhide_input=7]
> add path 'atkbd*' unhide
> add path 'kbd*' unhide
> add path 'joy*' unhide
> add path 'psm*' unhide
> add path sysmouse unhide
> add path 'ukbd*' unhide
> add path 'ums*' unhide
>
> [devfsrules_unhide_xorg=8]
> add path agpgart unhide
> #add path console unhide
> add path dri unhide
> add path 'dri/card*' unhide
> add path nvidiactl unhide
> add path 'nvidia*' unhide
> add path io unhide
> add path mem unhide
> add path pci unhide
> add path tty unhide
> add path ttyv0 unhide
> add path ttyv1 unhide
> add path ttyv8 unhide
>
> [devfsrules_unhide_kmem=11]
> add path kmem unhide
>
> [devfsrules_unhide_zfs=12]
> add path zfs unhide
>
> #
> # This allows to run a desktop system in a jail.  Think about what you want to
> # achieve before you use this, it opens up the entire machine to access from
> # this jail to any sophisticated program.
> #
> [devfsrules_jail_desktop=15]
> add include $devfsrules_hide_all
> add include $devfsrules_unhide_basic
> add include $devfsrules_unhide_login
> add include $devfsrules_unhide_audio
> add include $devfsrules_unhide_input
> add include $devfsrules_unhide_xorg
> add include $devfsrules_unhide_kmem
>
> [devfsrules_jail_desktop_withzfs=18]
> add include $devfsrules_hide_all
> add include $devfsrules_unhide_basic
> add include $devfsrules_unhide_login
> add include $devfsrules_unhide_audio
> add include $devfsrules_unhide_input
> add include $devfsrules_unhide_xorg
> add include $devfsrules_unhide_kmem
> add include $devfsrules_unhide_zfs
> ---snip---
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Alexander Leidinger
In reply to this post by Giulio Ferro

Quoting Giulio Ferro <[hidden email]> (from Mon, 4 Sep 2017  
08:51:10 +0200):

> On 10/08/2017 22:54, Alexander Leidinger wrote:
>>
>> Quoting Alan Somers <[hidden email]> (from Wed, 9 Aug 2017

>>> Unfortunately, you're not going to be able to run devd(8) in the jail.
>>> /dev/devctl can be opened by only one reader at a time, and that
>>> reader is always devd(8).  /dev/devctl2 is actually a completely
>>> different device with a totally different interface.  Apologies for
>>> the confusing names.  But you may not need to run a totally separate
>>> instance of devd.  The X server is probably trying to open either
>>> /var/run/devd.pipe or /var/run/devd.seqpacket.pipe.  ktrace would tell
>>> you which.  If you can bridge those sockets into the jail, then X
>>> would probably run.
>>
>> Apart from using an explicit config of devices instead of HAL /  
>> devd, if this is a X server connecting to a graphics card (instead  
>> of just a remote accessible framebuffer), the X-in-a-jail patches  
>> are needed, as the X server needs access to /dev/(k)mem and /dev/io  
>> (and /dev/drm).
>>
>
> Hi Alexander,
>
> as I said, I don't actually need to connect to any device, as this  
> Xorg server in the jail only uses xrdp as backend.
In this case you don't need my patches at all... I hope (my  
understanding is that the X server needs this kind of access to access  
hardware). And to answer your question in another mail, yes, the diff  
is for current, not for 11.x.

It's been a while since I looked last at the devd/hald <-> X11  
interaction, but back then it was only needed to auto-detect  
mouse/keyboard/..., so I wonder why xrdp needs it. Anyway, have a look  
to configure the config with static devices instead of devd/hald (see  
https://forums.freebsd.org/threads/7956/).

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
On 05/09/2017 15:15, Alexander Leidinger wrote:

>
> Quoting Giulio Ferro <[hidden email]> (from Mon, 4 Sep 2017
> 08:51:10 +0200):
>
>> On 10/08/2017 22:54, Alexander Leidinger wrote:
>>>
>>> Quoting Alan Somers <[hidden email]> (from Wed, 9 Aug 2017
>
>>>> Unfortunately, you're not going to be able to run devd(8) in the jail.
>>>> /dev/devctl can be opened by only one reader at a time, and that
>>>> reader is always devd(8).  /dev/devctl2 is actually a completely
>>>> different device with a totally different interface. Apologies for
>>>> the confusing names.  But you may not need to run a totally separate
>>>> instance of devd.  The X server is probably trying to open either
>>>> /var/run/devd.pipe or /var/run/devd.seqpacket.pipe.  ktrace would tell
>>>> you which.  If you can bridge those sockets into the jail, then X
>>>> would probably run.
>>>
>>> Apart from using an explicit config of devices instead of HAL /
>>> devd, if this is a X server connecting to a graphics card (instead
>>> of just a remote accessible framebuffer), the X-in-a-jail patches
>>> are needed, as the X server needs access to /dev/(k)mem and /dev/io
>>> (and /dev/drm).
>>>
>>
>> Hi Alexander,
>>
>> as I said, I don't actually need to connect to any device, as this
>> Xorg server in the jail only uses xrdp as backend.
>
> In this case you don't need my patches at all... I hope (my
> understanding is that the X server needs this kind of access to access
> hardware). And to answer your question in another mail, yes, the diff
> is for current, not for 11.x.
>
> It's been a while since I looked last at the devd/hald <-> X11
> interaction, but back then it was only needed to auto-detect
> mouse/keyboard/..., so I wonder why xrdp needs it. Anyway, have a look
> to configure the config with static devices instead of devd/hald (see
> https://forums.freebsd.org/threads/7956/).
>
> Bye,
> Alexander.
>



Hi Alexander, and thanks for your reply.


Actually I tried to apply the changes to xorg.conf, and now it doesn't
try to access devd anymore.


But it core-dumps for no apparent reason...


Here is my /etc/X11/xrdp/xorg.conf. It is the one generated by xrdp plus
the changes to the "ServerFlags" section

specified in your link:

-----------------------------------------------------------------------------------------------------------------------------------

Section "ServerLayout"
     Identifier "X11 Server"
     Screen "Screen (xrdpdev)"
     InputDevice "xrdpMouse" "CorePointer"
     InputDevice "xrdpKeyboard" "CoreKeyboard"
EndSection

Section "ServerFlags"
     Option "DontVTSwitch" "on"
     Option "DontZap" "off"
     Option "AllowEmptyInput" "off"
     Option "AutoAddDevices" "off"
EndSection

Section "Module"
     Load "dbe"
     Load "ddc"
     Load "extmod"
     Load "glx"
     Load "int10"
     Load "record"
     Load "vbe"
     Load "xorgxrdp"
     Load "fb"
EndSection

Section "InputDevice"
     Identifier "xrdpKeyboard"
     Driver "xrdpkeyb"
EndSection

Section "InputDevice"
     Identifier "xrdpMouse"
     Driver "xrdpmouse"
EndSection

Section "Monitor"
     Identifier "Monitor"
     Option "DPMS"
     HorizSync 30-80
     VertRefresh 60-75
     ModeLine "1920x1080" 138.500 1920 1968 2000 2080 1080 1083 1088
1111 +hsync -vsync
     ModeLine "1280x720" 74.25 1280 1720 1760 1980 720 725 730 750
+HSync +VSync
     Modeline "1368x768" 72.25 1368 1416 1448 1528 768 771 781 790
+hsync -vsync
     Modeline "1600x900" 119.00 1600 1696 1864 2128 900 901 904 932
-hsync +vsync
EndSection

Section "Device"
     Identifier "Video Card (xrdpdev)"
     Driver "xrdpdev"
EndSection

Section "Screen"
     Identifier "Screen (xrdpdev)"
     Device "Video Card (xrdpdev)"
     Monitor "Monitor"
     DefaultDepth 24
     SubSection "Display"
         Depth 24
         Modes "640x480" "800x600" "1024x768" "1280x720" "1280x1024"
"1600x900" "1920x1080"
     EndSubSection
EndSection
-----------------------------------------------------------------------------------------------------------------------------------



And here is my Xorg.log file:

-----------------------------------------------------------------------------------------------------------------------------------

[   796.772]
X.Org X Server 1.18.4
Release Date: 2016-07-19
[   796.772] X Protocol Version 11, Revision 0
[   796.772] Build Operating System: FreeBSD 11.0-RELEASE-p12 amd64
[   796.772] Current Operating System: FreeBSD xx.xx.xx 11.1-STABLE
FreeBSD 11.1-STABLE #0: Thu Aug 31 11:52:30 UTC 2017    
[hidden email]/usr/obj/usr/src/sys/MYKERN amd64
[   796.772] Build Date: 29 August 2017  01:51:45AM
[   796.772]
[   796.772] Current version of pixman: 0.34.0
[   796.772]     Before reporting problems, check http://wiki.x.org
     to make sure that you have the latest version.
[   796.772] Markers: (--) probed, (**) from config file, (==) default
setting,
     (++) from command line, (!!) notice, (II) informational,
     (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   796.772] (==) Log file: "/var/log/Xorg.11.log", Time: Tue Sep 5
14:17:24 2017
[   796.775] (++) Using config file: "/etc/X11/xrdp/xorg.conf"
[   796.775] (==) ServerLayout "X11 Server"
[   796.775] (**) |-->Screen "Screen (xrdpdev)" (0)
[   796.775] (**) |   |-->Monitor "Monitor"
[   796.777] (**) |   |-->Device "Video Card (xrdpdev)"
[   796.777] (**) |-->Input Device "xrdpMouse"
[   796.777] (**) |-->Input Device "xrdpKeyboard"
[   796.777] (**) Option "DontVTSwitch" "on"
[   796.777] (**) Option "DontZap" "off"
[   796.777] (**) Option "AutoAddDevices" "off"
[   796.777] (**) Not automatically adding devices
[   796.777] (==) Automatically enabling devices
[   796.777] (==) Not automatically adding GPU devices
[   796.777] (==) Max clients allowed: 256, resource mask: 0x1fffff
[   796.787] (==) FontPath set to:
     /usr/local/share/fonts/misc/,
     /usr/local/share/fonts/TTF/,
     /usr/local/share/fonts/OTF/,
     /usr/local/share/fonts/Type1/,
     /usr/local/share/fonts/100dpi/,
     /usr/local/share/fonts/75dpi/
[   796.787] (==) ModulePath set to "/usr/local/lib/xorg/modules"
[   796.789] (II) Loader magic: 0x813b70
[   796.789] (II) Module ABI versions:
[   796.789]     X.Org ANSI C Emulation: 0.4
[   796.789]     X.Org Video Driver: 20.0
[   796.789]     X.Org XInput driver : 22.1
[   796.789]     X.Org Server Extension : 9.0
[   796.789] (WW) checkDevMem: failed to open /dev/mem (Operation not
permitted)
[   796.789] (--) PCI:*(0:0:2:0) 1013:00b8:5853:0001 rev 0, Mem @
0xf0000000/33554432, 0xf3000000/4096, BIOS @ 0x????????/65536
[   796.789] (II) "glx" will be loaded. This was enabled by default and
also specified in the config file.
[   796.789] (II) LoadModule: "dbe"
[   796.789] (II) Module "dbe" already built-in
[   796.789] (II) LoadModule: "ddc"
[   796.789] (II) Module "ddc" already built-in
[   796.789] (II) LoadModule: "extmod"
[   796.789] (II) Module "extmod" already built-in
[   796.789] (II) LoadModule: "glx"
[   796.792] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[   796.821] (II) Module glx: vendor="X.Org Foundation"
[   796.821]     compiled for 1.18.4, module version = 1.0.0
[   796.821]     ABI class: X.Org Server Extension, version 9.0
[   796.821] (==) AIGLX enabled
[   796.822] (II) LoadModule: "int10"
[   796.823] (II) Loading /usr/local/lib/xorg/modules/libint10.so
[   796.825] (II) Module int10: vendor="X.Org Foundation"
[   796.825]     compiled for 1.18.4, module version = 1.0.0
[   796.825]     ABI class: X.Org Video Driver, version 20.0
[   796.825] (II) LoadModule: "record"
[   796.825] (II) Module "record" already built-in
[   796.825] (II) LoadModule: "vbe"
[   796.826] (II) Loading /usr/local/lib/xorg/modules/libvbe.so
[   796.827] (II) Module vbe: vendor="X.Org Foundation"
[   796.827]     compiled for 1.18.4, module version = 1.1.0
[   796.827]     ABI class: X.Org Video Driver, version 20.0
[   796.827] (II) LoadModule: "xorgxrdp"
[   796.828] (II) Loading /usr/local/lib/xorg/modules/libxorgxrdp.so
[   796.832] (II) Module XORGXRDP: vendor="X.Org Foundation"
[   796.832]     compiled for 1.18.4, module version = 1.0.0
[   796.832]     ABI class: X.Org Video Driver, version 20.0
[   796.832] xorgxrdpSetup:
[   796.832] (II) LoadModule: "fb"
[   796.832] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[   796.835] (II) Module fb: vendor="X.Org Foundation"
[   796.835]     compiled for 1.18.4, module version = 1.0.0
[   796.835]     ABI class: X.Org ANSI C Emulation, version 0.4
[   796.835] (II) LoadModule: "xrdpdev"
[   796.835] (II) Loading /usr/local/lib/xorg/modules/drivers/xrdpdev_drv.so
[   796.837] (II) Module XRDPDEV: vendor="X.Org Foundation"
[   796.837]     compiled for 1.18.4, module version = 1.0.0
[   796.837]     ABI class: X.Org Video Driver, version 20.0
[   796.837] xrdpdevSetup:
[   796.837] (II) LoadModule: "xrdpmouse"
[   796.837] (II) Loading /usr/local/lib/xorg/modules/input/xrdpmouse_drv.so
[   796.838] (II) Module XRDPMOUSE: vendor="X.Org Foundation"
[   796.838]     compiled for 1.18.4, module version = 1.0.0
[   796.838]     Module class: X.Org XInput Driver
[   796.838]     ABI class: X.Org XInput driver, version 22.1
[   796.838] rdpmousePlug:
[   796.838] (II) LoadModule: "xrdpkeyb"
[   796.838] (II) Loading /usr/local/lib/xorg/modules/input/xrdpkeyb_drv.so
[   796.839] (II) Module XRDPKEYB: vendor="X.Org Foundation"
[   796.839]     compiled for 1.18.4, module version = 1.0.0
[   796.839]     Module class: X.Org XInput Driver
[   796.839]     ABI class: X.Org XInput driver, version 22.1
[   796.839] rdpkeybPlug:
[   796.839] rdpIdentify:
[   796.839] (II) XRDPDEV: driver for xrdp: XRDPDEV
[   796.839] rdpDriverFunc: op 10
[   796.839] (WW) Falling back to old probe method for XRDPDEV
[   796.839] rdpProbe:
[   796.839] (II) Loading sub module "fb"
[   796.839] (II) LoadModule: "fb"
[   796.839] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[   796.839] (II) Module fb: vendor="X.Org Foundation"
[   796.839]     compiled for 1.18.4, module version = 1.0.0
[   796.839]     ABI class: X.Org ANSI C Emulation, version 0.4
[   796.839] (II) XRDPDEV(0): using default device
[   796.839] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card
support
[   796.839] rdpPreInit:
[   796.839] (**) XRDPDEV(0): Depth 24, (--) framebuffer bpp 32
[   796.839] (==) XRDPDEV(0): RGB weight 888
[   796.839] (==) XRDPDEV(0): Using gamma correction (1.0, 1.0, 1.0)
[   796.839] (==) XRDPDEV(0): Default visual is TrueColor
[   796.839] (==) XRDPDEV(0): DPI set to (96, 96)
[   796.839] (II) XRDPDEV(0):     mode "640x480" ok
[   796.839] (II) XRDPDEV(0):     mode "800x600" ok
[   796.839] (--) XRDPDEV(0): Virtual size is 800x600 (pitch 800)
[   796.839] (**) XRDPDEV(0):  Default mode "800x600": 36.0 MHz (scaled
from 0.0 MHz), 35.2 kHz, 56.2 Hz
[   796.839] (II) XRDPDEV(0): Modeline "800x600"x0.0   36.00  800 824
896 1024  600 601 603 625 +hsync +vsync (35.2 kHz d)
[   796.839] (==) Depth 24 pixmap format is 32 bpp
[   796.841] rdpScreenInit: virtualX 800 virtualY 600 rgbBits 8 depth 24
[   796.841] rdpScreenInit: pfbMemory bytes 1920000
[   796.841] rdpScreenInit: pfbMemory 0x807200000
[   796.843] rdpSimdInit: assigning yuv functions
[   796.843] rdpSimdInit: cpuid ax 1 cx 0 return ax 0x000306f2 bx
0x00020800 cx 0xfffa3203 dx 0x178bfbff
[   796.843] rdpSimdInit: sse2 amd64 yuv functions assigned
[   796.843] rdpXvInit: depth 24
[   796.845] (==) XRDPDEV(0): Backing store enabled
[   796.845] rdpClientConInit: kill disconnected [0] timeout [0] sec
[   796.845]
[   796.845] rdpScreenInit: out
[   796.846] (==) RandR enabled
[   796.846] MIT-SHM extension disabled due to lack of kernel support
[   796.852] (II) AIGLX: Screen 0 is not DRI2 capable
[   796.852] (EE) AIGLX: reverting to software rendering
[   797.431] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[   797.431] (II) AIGLX: Loaded and initialized swrast
[   797.431] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[   797.545] (II) Using input driver 'XRDPMOUSE' for 'xrdpMouse'
[   797.545] (**) Option "CorePointer"
[   797.545] (**) xrdpMouse: always reports core events
[   797.545] rdpmousePreInit: drv 0x803c15240 info 0x80ce72e20, flags 0x0
[   797.545] (II) XINPUT: Adding extended input device "xrdpMouse"
(type: Mouse, id 6)
[   797.545] rdpmouseControl: what 0
[   797.545] rdpmouseDeviceInit:
[   797.545] rdpmouseCtrl:
[   797.545] rdpRegisterInputCallback: type 1 proc 0x806da1d20
[   797.545] (**) xrdpMouse: (accel) keeping acceleration scheme 1
[   797.545] (**) xrdpMouse: (accel) acceleration profile 0
[   797.545] (**) xrdpMouse: (accel) acceleration factor: 2.000
[   797.545] (**) xrdpMouse: (accel) acceleration threshold: 4
[   797.545] rdpmouseControl: what 1
[   797.545] rdpmouseDeviceOn:
[   797.545] (II) Using input driver 'XRDPKEYB' for 'xrdpKeyboard'
[   797.545] (**) Option "CoreKeyboard"
[   797.545] (**) xrdpKeyboard: always reports core events
[   797.545] rdpkeybPreInit: drv 0x803c152c0 info 0x80ce72f60, flags 0x0
[   797.545] (II) XINPUT: Adding extended input device "xrdpKeyboard"
(type: Keyboard, id 7)
[   797.545] rdpkeybControl: what 0
[   797.545] rdpkeybDeviceInit:
[   797.568] rdpkeybChangeKeyboardControl:
[   797.568] rdpkeybChangeKeyboardControl: autoRepeat on
[   797.568] rdpRegisterInputCallback: type 0 proc 0x806fa41b0
[   797.568] rdpkeybControl: what 1
[   797.568] rdpkeybDeviceOn:
[   797.568] (II) config/devd: probing input devices...
[   797.568] (II) config/devd: adding input device (null) (/dev/kbdmux)
[   797.568] (II) AutoAddDevices is off - not adding device.
[   797.568] (II) config/devd: kbdmux is enabled, ignoring device atkbd0
[   797.568] (II) config/devd: adding input device (null) (/dev/sysmouse)
[   797.568] (II) AutoAddDevices is off - not adding device.
[   797.601] (II) config/devd: adding input device Mouse (/dev/psm0)
[   797.601] (II) AutoAddDevices is off - not adding device.
[   797.601] (EE) config/devd: fail to connect to devd
[   797.601] [config] failed to initialise devd
[   797.602] rdpSaveScreen:
[   797.602] rdpClientConGotConnection:
[   797.602] rdpClientConGotConnection: g_sck_accept ok new_sck 5
[   797.602] rdpClientConGotConnection: adding only clientCon
[   797.602] rdpDeferredRandR:
[   797.602] rdpResizeSession: width 1024 height 768
[   797.602]   calling RRScreenSizeSet
[   797.602] rdpRRScreenSetSize: width 1024 height 768 mmWidth 271
mmHeight 203
[   797.602] rdpRRGetInfo:
[   797.602]   screen resized to 1024x768
[   797.604]   RRScreenSizeSet ok 1
[   797.604] rdpResizeSession: width 1244 height 509
[   797.604]   calling RRScreenSizeSet
[   797.604] rdpRRScreenSetSize: width 1244 height 509 mmWidth 329
mmHeight 135
[   797.604] rdpRRGetInfo:
[   797.604]   screen resized to 1244x509
[   797.605]   RRScreenSizeSet ok 1
[   797.605] rdpClientConProcessMsgVersion: version 0 0 0 1
[   797.605] rdpClientConProcessScreenSizeMsg: set width 1244 height 509
bpp 16
[   797.605] rdpClientConProcessScreenSizeMsg: shmemid -1 shmemptr
0xffffffffffffffff
[   797.605] rdpClientConProcessMsgClientInput: invalidate x 0 y 0 cx
1244 cy 509
[   797.668] rdpInDeferredUpdateCallback:
[   797.668] rdpkeybChangeKeyboardControl:
[   797.668] rdpkeybChangeKeyboardControl: autoRepeat off
[   813.899] rdpClientConProcessMsgClientInfo:
[   813.899]   got client info bytes 5744
[   813.899]   jpeg support 0
[   813.899]   offscreen support 0
[   813.899]   offscreen size 0
[   813.899]   offscreen entries 0
[   813.899]   client supports glyph cache but server disabled
[   813.899]   client can not do offscreen to offscreen blits
[   813.899]   client can do new(color) cursor
[   813.899]   client can not do multimon
[   813.899] rdpRRSetRdpOutputs: numCrtcs 0 monitorCount 0
[   813.899] rdpRRSetRdpOutputs: add output 0 left 0 top 0 width 1244
height 509
[   813.900] rdpLoadLayout: keylayout 0x00000409 variant  display 11
[   813.900] rdpkeybChangeKeyboardControl:
[   813.900] rdpkeybChangeKeyboardControl: autoRepeat on
[   813.900] rdpkeybChangeKeyboardControl:
[   813.900] rdpkeybChangeKeyboardControl: autoRepeat on
[   813.910] (EE)
[   813.910] (EE) Backtrace:
[   813.912] (EE) 0: /usr/local/bin/Xorg (OsInit+0x38a) [0x5abfba]
[   813.914] (EE) 1: /lib/libthr.so.3 (_pthread_sigmask+0x544) [0x8025cbd94]
[   813.915] (EE) 2: /lib/libthr.so.3 (_pthread_getspecific+0xe5f)
[0x8025cbbef]
[   813.916] (EE) 3: ? (?+0xe5f) [0x7ffffffffe62]
[   813.918] (EE) 4: /usr/local/lib/xorg/modules/libxorgxrdp.so
(rdpCapture+0xf60) [0x806771aa0]
[   813.919] (EE) 5: /usr/local/lib/xorg/modules/libxorgxrdp.so
(rdpClientConAddAllBox+0x408) [0x80676fbf8]
[   813.920] (EE) 6: /usr/local/lib/xorg/modules/libxorgxrdp.so
(rdpClientConAddDirtyScreenReg+0x3c3) [0x80676ef13]
[   813.921] (EE) 7: /usr/local/bin/Xorg (WaitForSomething+0x103e)
[0x5a47ce]
[   813.922] (EE) 8: /usr/local/bin/Xorg (UpdateCurrentTimeIf+0x121)
[0x431621]
[   813.923] (EE) 9: /usr/local/bin/Xorg (remove_fs_handlers+0x597)
[0x43b697]
[   813.924] (EE) 10: /usr/local/bin/Xorg (_start+0x17f) [0x42506f]
[   813.925] (EE) 11: ? (?+0x17f) [0x80083617f]
[   813.925] (EE)
[   813.925] (EE) Segmentation fault at address 0xffffffffffffffff
[   813.925] (EE)
Fatal server error:
[   813.925] (EE) Caught signal 11 (Segmentation fault). Server aborting
[   813.925] (EE)
[   813.925] (EE)
Please consult the The X.Org Foundation support
      at http://wiki.x.org
  for help.
[   813.925] (EE) Please also check the log file at
"/var/log/Xorg.11.log" for additional information.
[   813.925] (EE)
[   813.925] rdpmouseControl: what 4
[   813.925] rdpkeybControl: what 4
[   813.925] rdpLeaveVT:
[   813.925] (EE) Server terminated with error (1). Closing log file.

-----------------------------------------------------------------------------------------------------------------------------------


I have a custom kernel which include GENERIC and only the VIMAGE +
bridge support is added.


Can you make something of it? Or do you have any suggestions about what
I could try?


Thanks in advance!


Giulio

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Mark Millard-2
[I've no particular expertise but I noticed in what you
reported . . .]

On 2017-Sep-5, at 11:25 AM, Giulio Ferro <auryn at zirakzigil.org> wrote:

> . . .
>
> Actually I tried to apply the changes to xorg.conf, and now it doesn't try to access devd anymore.
>
> . . .
> [   797.601] (EE) config/devd: fail to connect to devd
> . . .

I expect that the "(EE)" indicates an error is being reported
and so it is intended as more than an informational notice.


===
Mark Millard
markmi at dsl-only.net

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
On 05/09/2017 20:35, Mark Millard wrote:

> [I've no particular expertise but I noticed in what you
> reported . . .]
>
> On 2017-Sep-5, at 11:25 AM, Giulio Ferro <auryn at zirakzigil.org> wrote:
>
>> . . .
>>
>> Actually I tried to apply the changes to xorg.conf, and now it doesn't try to access devd anymore.
>>
>> . . .
>> [   797.601] (EE) config/devd: fail to connect to devd
>> . . .
> I expect that the "(EE)" indicates an error is being reported
> and so it is intended as more than an informational notice.
>


Hi Mark,

yes, I missed that! Thanks for raising.

Then I guess it's the same error as occurred before.

It seems that xorg can't help trying to access devd and so it fails in
jail...

Giulio
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Alexander Leidinger
Quoting Giulio Ferro <[hidden email]> (from Tue, 5 Sep 2017  
20:41:41 +0200):

> On 05/09/2017 20:35, Mark Millard wrote:
>> [I've no particular expertise but I noticed in what you
>> reported . . .]
>>
>> On 2017-Sep-5, at 11:25 AM, Giulio Ferro <auryn at zirakzigil.org> wrote:
>>
>>> . . .
>>>
>>> Actually I tried to apply the changes to xorg.conf, and now it  
>>> doesn't try to access devd anymore.
>>>
>>> . . .
>>> [   797.601] (EE) config/devd: fail to connect to devd
>>> . . .
>> I expect that the "(EE)" indicates an error is being reported
>> and so it is intended as more than an informational notice.
>>
>
>
> Hi Mark,
>
> yes, I missed that! Thanks for raising.
>
> Then I guess it's the same error as occurred before.
>
> It seems that xorg can't help trying to access devd and so it fails  
> in jail...
There are several EE entries in the log.

[   796.846] MIT-SHM extension disabled due to lack of kernel support
[   796.852] (II) AIGLX: Screen 0 is not DRI2 capable
[   796.852] (EE) AIGLX: reverting to software rendering
[   797.431] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer

I don't expect this to be critical.

Not sure about the devd one.
The segmentation fault is for sure an issue which prevents it from  
working, but I don't know if this is related to one of the EE above or  
not. You would have to check in the X.org / xrdp area for help (or if  
you have updated some pieces like OS/jail/kernel/ports since you have  
installed xrdp, you could try a fresh install of everything to  
rule-out some inconsistencies which could show up in some edge-cases).

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
Hi Alexander,

I've installed everything after my custom kernel was installed. And as I said, it differs from GENERIC only for the addition of VIMAGE and bridge.

What I can try to do is installing your patches so to remove the devd issue, and see if it starts like this.

Can you point me to patches for 11.1 stable?

Thanks
Giulio


> Il giorno 06 set 2017, alle ore 12:25, Alexander Leidinger <[hidden email]> ha scritto:
>
> Quoting Giulio Ferro <[hidden email]> (from Tue, 5 Sep 2017 20:41:41 +0200):
>
>>> On 05/09/2017 20:35, Mark Millard wrote:
>>> [I've no particular expertise but I noticed in what you
>>> reported . . .]
>>>
>>>> On 2017-Sep-5, at 11:25 AM, Giulio Ferro <auryn at zirakzigil.org> wrote:
>>>>
>>>> . . .
>>>>
>>>> Actually I tried to apply the changes to xorg.conf, and now it doesn't try to access devd anymore.
>>>>
>>>> . . .
>>>> [   797.601] (EE) config/devd: fail to connect to devd
>>>> . . .
>>> I expect that the "(EE)" indicates an error is being reported
>>> and so it is intended as more than an informational notice.
>>>
>>
>>
>> Hi Mark,
>>
>> yes, I missed that! Thanks for raising.
>>
>> Then I guess it's the same error as occurred before.
>>
>> It seems that xorg can't help trying to access devd and so it fails in jail...
>
> There are several EE entries in the log.
>
> [   796.846] MIT-SHM extension disabled due to lack of kernel support
> [   796.852] (II) AIGLX: Screen 0 is not DRI2 capable
> [   796.852] (EE) AIGLX: reverting to software rendering
> [   797.431] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
>
> I don't expect this to be critical.
>
> Not sure about the devd one.
> The segmentation fault is for sure an issue which prevents it from working, but I don't know if this is related to one of the EE above or not. You would have to check in the X.org / xrdp area for help (or if you have updated some pieces like OS/jail/kernel/ports since you have installed xrdp, you could try a fresh install of everything to rule-out some inconsistencies which could show up in some edge-cases).
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Alexander Leidinger

Quoting Giulio Ferro <[hidden email]> (from Wed, 6 Sep 2017  
14:13:52 +0200):

> Hi Alexander,
>
> I've installed everything after my custom kernel was installed. And  
> as I said, it differs from GENERIC only for the addition of VIMAGE  
> and bridge.
>
> What I can try to do is installing your patches so to remove the  
> devd issue, and see if it starts like this.
>
> Can you point me to patches for 11.1 stable?
Attached, patch against releng-11.1. Beware, this is not even  
compile-tested. And you need the modifications described in a previous  
mail for /etc/devfs.rules.

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

x11_in_jail__releng_11_1.diff (4K) Download Attachment
attachment1 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
On 06/09/2017 22:19, Alexander Leidinger wrote:

>
> Quoting Giulio Ferro <[hidden email]> (from Wed, 6 Sep 2017
> 14:13:52 +0200):
>
>> Hi Alexander,
>>
>> I've installed everything after my custom kernel was installed. And
>> as I said, it differs from GENERIC only for the addition of VIMAGE
>> and bridge.
>>
>> What I can try to do is installing your patches so to remove the devd
>> issue, and see if it starts like this.
>>
>> Can you point me to patches for 11.1 stable?
>
> Attached, patch against releng-11.1. Beware, this is not even
> compile-tested. And you need the modifications described in a previous
> mail for /etc/devfs.rules.
>
> Bye,
> Alexander.
>

Hi Alexander,


I've applied the patch, compiled and install the new kernel.


Here's my jail.conf


------------------------------------------------------------

exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset=1;
allow.kmem_access;


path = "/usr/home/jails/$name";

xx {
         host.hostname = "xx.xx.xx";
         vnet;
         vnet.interface = epair0b, epair1b;
         persist;
      }


------------------------------------------------------------


But the problem now is that the jail doesn't start, if fact it seems it
doesn't recognise the parameter:


# /etc/rc.d/jail start
Starting jails:jail: wsj: unknown parameter: allow.kmem_access


I've tried both putting it in the general section and in the xx jail
section, but same result.


Should I put it somewhere else?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
In reply to this post by Alexander Leidinger
Hi Alexander,

I've installed everything after my custom kernel was installed. And as I said, it differs from GENERIC only for the addition of VIMAGE and bridge.

What I can try to do is installing your patches so to remove the devd issue, and see if it starts like this.

Can you point me to patches for 11.1 stable?

Thanks
Giulio


> Il giorno 06 set 2017, alle ore 12:25, Alexander Leidinger <[hidden email]> ha scritto:
>
> Quoting Giulio Ferro <[hidden email]> (from Tue, 5 Sep 2017 20:41:41 +0200):
>
>>> On 05/09/2017 20:35, Mark Millard wrote:
>>> [I've no particular expertise but I noticed in what you
>>> reported . . .]
>>>
>>>> On 2017-Sep-5, at 11:25 AM, Giulio Ferro <auryn at zirakzigil.org> wrote:
>>>>
>>>> . . .
>>>>
>>>> Actually I tried to apply the changes to xorg.conf, and now it doesn't try to access devd anymore.
>>>>
>>>> . . .
>>>> [   797.601] (EE) config/devd: fail to connect to devd
>>>> . . .
>>> I expect that the "(EE)" indicates an error is being reported
>>> and so it is intended as more than an informational notice.
>>
>>
>> Hi Mark,
>>
>> yes, I missed that! Thanks for raising.
>>
>> Then I guess it's the same error as occurred before.
>>
>> It seems that xorg can't help trying to access devd and so it fails in jail...
>
> There are several EE entries in the log.
>
> [   796.846] MIT-SHM extension disabled due to lack of kernel support
> [   796.852] (II) AIGLX: Screen 0 is not DRI2 capable
> [   796.852] (EE) AIGLX: reverting to software rendering
> [   797.431] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
>
> I don't expect this to be critical.
>
> Not sure about the devd one.
> The segmentation fault is for sure an issue which prevents it from working, but I don't know if this is related to one of the EE above or not. You would have to check in the X.org / xrdp area for help (or if you have updated some pieces like OS/jail/kernel/ports since you have installed xrdp, you could try a fresh install of everything to rule-out some inconsistencies which could show up in some edge-cases).
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
In reply to this post by Alexander Leidinger
On 06/09/2017 22:19, Alexander Leidinger wrote:

>
> Quoting Giulio Ferro <[hidden email]> (from Wed, 6 Sep 2017
> 14:13:52 +0200):
>
>> Hi Alexander,
>>
>> I've installed everything after my custom kernel was installed. And as
>> I said, it differs from GENERIC only for the addition of VIMAGE and
>> bridge.
>>
>> What I can try to do is installing your patches so to remove the devd
>> issue, and see if it starts like this.
>>
>> Can you point me to patches for 11.1 stable?
>
> Attached, patch against releng-11.1. Beware, this is not even
> compile-tested. And you need the modifications described in a previous
> mail for /etc/devfs.rules.
>
> Bye,
> Alexander.
>

Hi Alexander,


I've applied the patch, compiled and install the new kernel.


Here's my jail.conf


------------------------------------------------------------

exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset=1;
allow.kmem_access;


path = "/usr/home/jails/$name";

xx {
         host.hostname = "xx.xx.xx";
         vnet;
         vnet.interface = epair0b, epair1b;
         persist;
      }


------------------------------------------------------------


But the problem now is that the jail doesn't start, if fact it seems it
doesn't recognise the parameter:


# /etc/rc.d/jail start
Starting jails:jail: wsj: unknown parameter: allow.kmem_access


I've tried both putting it in the general section and in the xx jail
section, but same result.


Should I put it somewhere else?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Alexander Leidinger
In reply to this post by Giulio Ferro
Quoting Giulio Ferro <[hidden email]> (from Thu, 7 Sep 2017  
08:54:45 +0200):


> I've applied the patch, compiled and install the new kernel.
>
>
> Here's my jail.conf
[jail.conf]

> But the problem now is that the jail doesn't start, if fact it seems  
> it doesn't recognise the parameter:
>
>
> # /etc/rc.d/jail start
> Starting jails:jail: wsj: unknown parameter: allow.kmem_access
>
>
> I've tried both putting it in the general section and in the xx jail  
> section, but same result.
>
>
> Should I put it somewhere else?
I don't use jail.conf, I use ezjail or iocage. From my reading of the  
jail-command source code, it looks like it should work there if it is  
OK in the kernel (no modification to the source of the jail-command  
necessary). This suggests it is not really OK in the kernel.

Please run this:
strings /boot/kernel/kernel| grep allow.kmem

If it doesn't print out "allow.kmem_access", then your kernel doesn't  
contain the patch.

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
On 09/09/2017 15:03, Alexander Leidinger wrote:
> Please run this:
> strings /boot/kernel/kernel| grep allow.kmem
>
> If it doesn't print out "allow.kmem_access", then your kernel doesn't
> contain the patch.
>
> Bye,
> Alexander.
>

# strings /boot/kernel/kernel | grep allow.kmem
allow.kmem_access

So it seems the kernel is ok...


  Maybe I can set this value at boot in /boot/loader.conf?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Alexander Leidinger
Quoting Giulio Ferro <[hidden email]> (from Mon, 11 Sep 2017  
06:42:01 +0200):

> On 09/09/2017 15:03, Alexander Leidinger wrote:
>> Please run this:
>> strings /boot/kernel/kernel| grep allow.kmem
>>
>> If it doesn't print out "allow.kmem_access", then your kernel  
>> doesn't contain the patch.
>>
>> Bye,
>> Alexander.
>>
>
> # strings /boot/kernel/kernel | grep allow.kmem
> allow.kmem_access
>
> So it seems the kernel is ok...
>
>
>  Maybe I can set this value at boot in /boot/loader.conf?
No, this is not a loader.conf setting.

Can you try to use "old style" jail config = settings in rc.conf  
instead of using jail.conf on a test system? It may be that you need  
to move away the jail.conf temporary, I haven't checked what takes  
precedence when both (rc.conf and jail.conf) settings are there.

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: devd in jail

Giulio Ferro
Hi Alexander,

I don't know how to set your parameter in old style jails in rc.conf

In there, new parameters are mapped to old style jail_xxx entries, but there are none for your parameter unless I'm mistaken.

Can you please tell me exactly what I should put in rc.conf? I've already moved the jail.conf file

Thanks.

Giulio

> Il giorno 11 set 2017, alle ore 16:12, Alexander Leidinger <[hidden email]> ha scritto:
>
> Quoting Giulio Ferro <[hidden email]> (from Mon, 11 Sep 2017 06:42:01 +0200):
>
>>> On 09/09/2017 15:03, Alexander Leidinger wrote:
>>> Please run this:
>>> strings /boot/kernel/kernel| grep allow.kmem
>>>
>>> If it doesn't print out "allow.kmem_access", then your kernel doesn't contain the patch.
>>>
>>> Bye,
>>> Alexander.
>>>
>>
>> # strings /boot/kernel/kernel | grep allow.kmem
>> allow.kmem_access
>>
>> So it seems the kernel is ok...
>>
>>
>> Maybe I can set this value at boot in /boot/loader.conf?
>
> No, this is not a loader.conf setting.
>
> Can you try to use "old style" jail config = settings in rc.conf instead of using jail.conf on a test system? It may be that you need to move away the jail.conf temporary, I haven't checked what takes precedence when both (rc.conf and jail.conf) settings are there.
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
12