On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> Hiltjo Posthuma <[email protected]> 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
