Hiltjo Posthuma <hil...@codemadness.org> 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
>
