incorrect permissions on /var/log after debootstrap

[Frederic Van Espen]

we are debootstrapping a full bionic distribution into a directory. After debootstrapping the permissions on /var/log are incorrect, causing rsyslog to fail because it cannot write into the directory to create the various files.

Also, in the postinst of the rsyslog package I see that systemd-tmpfiles is attempted to be used to create the files defined in /usr/lib/tmpfiles.d/00rsyslog.conf, but from what I can tell this will never work because of the systemd-tmpfiles manpage:
       --create
           If this option is passed, all files and directories marked with f, F, w, d, D, v, p, L, c, b, m in the configuration files are
           created or written to. Files and directories marked with z, Z, t, T, a, and A have their ownership, access mode and security
           labels set.

Since the files are configured with type "z" only ownership, access mode and security will be updated.

# lsb_release -rd
Description: Ubuntu 18.04.1 LTS
Release: 18.04

# apt-cache policy rsyslog
rsyslog:
  Installed: 8.32.0-1ubuntu4
  Candidate: 8.32.0-1ubuntu4
  Version table:
 *** 8.32.0-1ubuntu4 100
        100 /var/lib/dpkg/status

[Frederic Van Espen (frederic-ve)]

Actually, it looks like this is already fixed in cosmic. Can this be ported to bionic as well?

[Frederic Van Espen (frederic-ve)]

Sorry for the noise, it seems this is not related to rsyslog after all. In our install process we are moving /var/log to another partition (mounted in /data/) and then symlink it to /var/log. Permissions are set up properly and work while the system is running. When the system is rebooted though there is an unknown process changing the permissions of /data/log, my best guess something related to systemd.

When we bind mount /data/log in /var/log directory we don't have this issue though.

[Steve Beattie (sbeattie)]

Thanks for clarifying, closing.