Questions about syspatch(8) mtree(8) behaviour

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

Questions about syspatch(8) mtree(8) behaviour

Hiltjo Posthuma
Hi,

I have three questions regarding a behaviour of syspatch(8) with mtree(8).

1. I noticed when applying patches it resets some permissions of new, but also of
existing directories on the system using mtree(8).

In the shellscript syspatch(8) there is a function:

trap_handler():
        # in case a patch added a new directory (install -D)
        if [[ -n ${_PATCHES} ]]; then
                mtree -qdef /etc/mtree/4.4BSD.dist -p / -U >/dev/null
                [[ -f /var/sysmerge/xetc.tgz ]] &&
                        mtree -qdef /etc/mtree/BSD.x11.dist -p / -U >/dev/null
        fi

Here the comment says: "in case a patch added a new directory (install -D)".
This is true, but it also applies to existing directories and resets
permissions, ownership, etc.

A real-world example: on my system after applying syspatch this changed
permissions of an existing directory and a daemon (mysqld) failed to start,
because it could not access a UNIX domain socket file in the www chroot.

Is this intended? If so should this behaviour perhaps get documented in the man
page? I can write a patch if so.

2. This code-path is called when $_PATCHES is set, thus when patches are
available and are being applied, but on patch rollback (syspatch -r or -R) it
does not run mtree. Wouldn't it be more consistent to also run mtree after
patch rollback?

3. With an other case on another machine with low disk-space the following
occurred: syspatch is run and ran out of disk-space while applying patches: "No
space left on sd0f, aborting", but it still ran mtree and reset the permissions
on "SIGEXIT". Wouldn't it make more sense to not change anything if no patch
could be applied?

Thanks for your time,

--
Kind regards,
Hiltjo

Reply | Threaded
Open this post in threaded view
|

Re: Questions about syspatch(8) mtree(8) behaviour

Theo de Raadt-2
Hiltjo Posthuma <[hidden email]> wrote:

> Hi,
>
> I have three questions regarding a behaviour of syspatch(8) with mtree(8).
>
> 1. I noticed when applying patches it resets some permissions of new, but also of
> existing directories on the system using mtree(8).
>
> In the shellscript syspatch(8) there is a function:
>
> trap_handler():
>         # in case a patch added a new directory (install -D)
>         if [[ -n ${_PATCHES} ]]; then
>                 mtree -qdef /etc/mtree/4.4BSD.dist -p / -U >/dev/null
>                 [[ -f /var/sysmerge/xetc.tgz ]] &&
>                         mtree -qdef /etc/mtree/BSD.x11.dist -p / -U >/dev/null
>         fi
>
> Here the comment says: "in case a patch added a new directory (install -D)".
> This is true, but it also applies to existing directories and resets
> permissions, ownership, etc.
>
> A real-world example: on my system after applying syspatch this changed
> permissions of an existing directory and a daemon (mysqld) failed to start,
> because it could not access a UNIX domain socket file in the www chroot.

A very long mail without being 100% PRECISE.

> Is this intended? If so should this behaviour perhaps get documented in the man
> page? I can write a patch if so.

Intentional.  As a general rule if you change a system component, you own
all the pieces.

But I guess you did chmod a+wrxt / or something, right?  I have to assume
so, because your mail is not PRECISE.


>
> 2. This code-path is called when $_PATCHES is set, thus when patches are
> available and are being applied, but on patch rollback (syspatch -r or -R) it
> does not run mtree. Wouldn't it be more consistent to also run mtree after
> patch rollback?
>
> 3. With an other case on another machine with low disk-space the following
> occurred: syspatch is run and ran out of disk-space while applying patches: "No
> space left on sd0f, aborting", but it still ran mtree and reset the permissions
> on "SIGEXIT". Wouldn't it make more sense to not change anything if no patch
> could be applied?
>
> Thanks for your time,
>
> --
> Kind regards,
> Hiltjo
>

Reply | Threaded
Open this post in threaded view
|

Re: Questions about syspatch(8) mtree(8) behaviour

Hiltjo Posthuma
On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:

> Hiltjo Posthuma <[hidden email]> wrote:
>
> > Hi,
> >
> > I have three questions regarding a behaviour of syspatch(8) with mtree(8).
> >
> > 1. I noticed when applying patches it resets some permissions of new, but also of
> > existing directories on the system using mtree(8).
> >
> > In the shellscript syspatch(8) there is a function:
> >
> > trap_handler():
> >         # in case a patch added a new directory (install -D)
> >         if [[ -n ${_PATCHES} ]]; then
> >                 mtree -qdef /etc/mtree/4.4BSD.dist -p / -U >/dev/null
> >                 [[ -f /var/sysmerge/xetc.tgz ]] &&
> >                         mtree -qdef /etc/mtree/BSD.x11.dist -p / -U >/dev/null
> >         fi
> >
> > Here the comment says: "in case a patch added a new directory (install -D)".
> > This is true, but it also applies to existing directories and resets
> > permissions, ownership, etc.
> >
> > A real-world example: on my system after applying syspatch this changed
> > permissions of an existing directory and a daemon (mysqld) failed to start,
> > because it could not access a UNIX domain socket file in the www chroot.
>
> A very long mail without being 100% PRECISE.
>
> > Is this intended? If so should this behaviour perhaps get documented in the man
> > page? I can write a patch if so.
>
> Intentional.  As a general rule if you change a system component, you own
> all the pieces.
>
> But I guess you did chmod a+wrxt / or something, right?  I have to assume
> so, because your mail is not PRECISE.
>

In this particular case it was the directory /var/www/run. The default
permissions are as specified in /etc/mtree/4.4BSD.dist:

        run                     type=dir uname=root gname=daemon mode=755

I changed it from 755 to 775 (still root:daemon) so both mysqld and PHP could
access the UNIX domain socket in the www chroot (/var/www).

I was a bit surprised syspatch silently changed it back to 755 and thus broke
my setup.  Maybe having mtree be more verbose or have a sentence documenting it
in the syspatch(8) man page would help. I would be happy to write a patch for
this.


> >
> > 2. This code-path is called when $_PATCHES is set, thus when patches are
> > available and are being applied, but on patch rollback (syspatch -r or -R) it
> > does not run mtree. Wouldn't it be more consistent to also run mtree after
> > patch rollback?
> >
> > 3. With an other case on another machine with low disk-space the following
> > occurred: syspatch is run and ran out of disk-space while applying patches: "No
> > space left on sd0f, aborting", but it still ran mtree and reset the permissions
> > on "SIGEXIT". Wouldn't it make more sense to not change anything if no patch
> > could be applied?
> >
> > Thanks for your time,
> >

--
Kind regards,
Hiltjo

Reply | Threaded
Open this post in threaded view
|

Re: Questions about syspatch(8) mtree(8) behaviour

Antoine Jacoutot-7
On Mon, Sep 02, 2019 at 08:58:01PM +0200, Hiltjo Posthuma wrote:

> On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> > Hiltjo Posthuma <[hidden email]> wrote:
> >
> > > Hi,
> > >
> > > I have three questions regarding a behaviour of syspatch(8) with mtree(8).
> > >
> > > 1. I noticed when applying patches it resets some permissions of new, but also of
> > > existing directories on the system using mtree(8).
> > >
> > > In the shellscript syspatch(8) there is a function:
> > >
> > > trap_handler():
> > >         # in case a patch added a new directory (install -D)
> > >         if [[ -n ${_PATCHES} ]]; then
> > >                 mtree -qdef /etc/mtree/4.4BSD.dist -p / -U >/dev/null
> > >                 [[ -f /var/sysmerge/xetc.tgz ]] &&
> > >                         mtree -qdef /etc/mtree/BSD.x11.dist -p / -U >/dev/null
> > >         fi
> > >
> > > Here the comment says: "in case a patch added a new directory (install -D)".
> > > This is true, but it also applies to existing directories and resets
> > > permissions, ownership, etc.
> > >
> > > A real-world example: on my system after applying syspatch this changed
> > > permissions of an existing directory and a daemon (mysqld) failed to start,
> > > because it could not access a UNIX domain socket file in the www chroot.
> >
> > A very long mail without being 100% PRECISE.
> >
> > > Is this intended? If so should this behaviour perhaps get documented in the man
> > > page? I can write a patch if so.
> >
> > Intentional.  As a general rule if you change a system component, you own
> > all the pieces.
> >
> > But I guess you did chmod a+wrxt / or something, right?  I have to assume
> > so, because your mail is not PRECISE.
> >
>
> In this particular case it was the directory /var/www/run. The default
> permissions are as specified in /etc/mtree/4.4BSD.dist:
>
> run                     type=dir uname=root gname=daemon mode=755
>
> I changed it from 755 to 775 (still root:daemon) so both mysqld and PHP could
> access the UNIX domain socket in the www chroot (/var/www).

Why don't you do what the mariadb readme advises?

chrooted daemons and MariaDB socket
===================================

For external program running under a chroot(8) to be able to access the
MariaDB server without using a network connection, the socket must be
placed inside the chroot.

e.g. httpd(8) or nginx(8): connecting to MariaDB from PHP
---------------------------------------------------------
Create a directory for the MariaDB socket:

    # install -d -m 0711 -o _mysql -g _mysql /var/www/var/run/mysql

Adjust ${SYSCONFDIR}/my.cnf to use the socket in the chroot - this
applies to both client and server processes:

    [client-server]
    socket = /var/www/var/run/mysql/mysql.sock


--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: Questions about syspatch(8) mtree(8) behaviour

Hiltjo Posthuma
On Tue, Sep 03, 2019 at 08:51:09AM +0200, Antoine Jacoutot wrote:

> On Mon, Sep 02, 2019 at 08:58:01PM +0200, Hiltjo Posthuma wrote:
> > On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> > > Hiltjo Posthuma <[hidden email]> wrote:
> > >
> > > > Hi,
> > > >
> > > > I have three questions regarding a behaviour of syspatch(8) with mtree(8).
> > > >
> > > > 1. I noticed when applying patches it resets some permissions of new, but also of
> > > > existing directories on the system using mtree(8).
> > > >
> > > > In the shellscript syspatch(8) there is a function:
> > > >
> > > > trap_handler():
> > > >         # in case a patch added a new directory (install -D)
> > > >         if [[ -n ${_PATCHES} ]]; then
> > > >                 mtree -qdef /etc/mtree/4.4BSD.dist -p / -U >/dev/null
> > > >                 [[ -f /var/sysmerge/xetc.tgz ]] &&
> > > >                         mtree -qdef /etc/mtree/BSD.x11.dist -p / -U >/dev/null
> > > >         fi
> > > >
> > > > Here the comment says: "in case a patch added a new directory (install -D)".
> > > > This is true, but it also applies to existing directories and resets
> > > > permissions, ownership, etc.
> > > >
> > > > A real-world example: on my system after applying syspatch this changed
> > > > permissions of an existing directory and a daemon (mysqld) failed to start,
> > > > because it could not access a UNIX domain socket file in the www chroot.
> > >
> > > A very long mail without being 100% PRECISE.
> > >
> > > > Is this intended? If so should this behaviour perhaps get documented in the man
> > > > page? I can write a patch if so.
> > >
> > > Intentional.  As a general rule if you change a system component, you own
> > > all the pieces.
> > >
> > > But I guess you did chmod a+wrxt / or something, right?  I have to assume
> > > so, because your mail is not PRECISE.
> > >
> >
> > In this particular case it was the directory /var/www/run. The default
> > permissions are as specified in /etc/mtree/4.4BSD.dist:
> >
> > run                     type=dir uname=root gname=daemon mode=755
> >
> > I changed it from 755 to 775 (still root:daemon) so both mysqld and PHP could
> > access the UNIX domain socket in the www chroot (/var/www).
>
> Why don't you do what the mariadb readme advises?
>
> chrooted daemons and MariaDB socket
> ===================================
>
> For external program running under a chroot(8) to be able to access the
> MariaDB server without using a network connection, the socket must be
> placed inside the chroot.
>
> e.g. httpd(8) or nginx(8): connecting to MariaDB from PHP
> ---------------------------------------------------------
> Create a directory for the MariaDB socket:
>
>     # install -d -m 0711 -o _mysql -g _mysql /var/www/var/run/mysql
>
> Adjust ${SYSCONFDIR}/my.cnf to use the socket in the chroot - this
> applies to both client and server processes:
>
>     [client-server]
>     socket = /var/www/var/run/mysql/mysql.sock
>
>
> --
> Antoine
>

Thanks, I think I understand the ideas behind it now and will keep it in mind.

--
Kind regards,
Hiltjo