[mythtv-users] mythbackendpre.log permissions

Stephen Worthington stephen_agent at jsw.gen.nz
Thu Mar 14 01:31:11 UTC 2024

On Wed, 13 Mar 2024 17:47:00 -0400, you wrote:

>I have the mythfrontendpre.sh script setup fine and discovering my two
>hdhomerun devices before starting the backend. However, I'm getting
>permission denied on writing /var/log/mythtv/mythbackendpre.log file.
>A lack of sleep has shot my Linux brain today. I figure I need to touch to
>create an empty file. The other logs in the dir are syslog:adm but what's
>the proper chmod?
>[reaches for second coffee]

The syslog:adm permissions on the log files works because the log
messages are being sent to syslog (rsyslogd) on port 514 and the
rsyslogd daemon receives the messages and sorts out where to write
them to, in accordance with its /etc/rsyslog.conf and /etc/rsyslog.d/*
config files.  So the actual file writing is being done by a program
running under user syslog.

Unfortunately, unless you do something to send messages to rsyslogd in
your script instead of writing directly to a log file, the script
needs access to the /var/log directories and the log file it is
writing to under its own user or group.  This is a complex permissions
problem, depending usually on group memberships.  Your frontend user
will usually belong to the syslog and adm groups, which helps, but
your mythtv user will not.

So what user and group are being used to run mythfrontendpre.sh?  Is
it run under user mythtv, or your frontend user?

In practical terms, doing commands like this:

sudo touch /var/log/mythtv/mylogfile.log
sudo chown syslog:adm /var/log/mythtv/mylogfile.log
sudo chmod a+w /var/log/mythtv/mylogfile.log

normally works, but it is less than ideal as it allows universal write
access to the log file.  Or running your script as root will always
work.  Or putting your log files in /tmp.  Or writing an "sudoers"
helper script that has the right permissions, and calling that script
from your actual script.  I have done all of the above at various
times for various reasons.  And also written scripts in Python instead
of bash, so I can use Python's excellent logging capabilities, which
includes the ability to send things to syslog.

It is always possible to use ACLs (Access Control Lists) instead of
the ordinary permissions mechanisms, which allows fine grained access.
See the setfacl and getfacl commands and also "man acl".  Most Linux
distros have ACLs enabled in the kernel now, and the system does use
them in various places, but you normally do not notice as the usual
listing tools like ls do not show the ACLs.  As an example, I run a
mosquitto server (running under user mosquitto), which needs to use my
Let's Encrypt certificates to allow encrypted connections.  So in the
script I run when the certificates are automatically updated, I have

setfacl -R -m u:mosquitto:rX /etc/letsencrypt/{live,archive}

which gives the mosquitto user read access to the directory where the
links to the current certificates are (live) and to the directory
where the actual certificate files are (archive).  So to allow
programs running as the mythtv user to write to a log file, this might

sudo touch /var/log/mythtv/mylogfile.log
sudo chown syslog:adm /var/log/mythtv/mylogfile.log
sudo setfacl -m u:mythtv:rwx /var/log/mythtv/mylogfile.log

I have not actually tried that setfacl command though - I might have
missed something.

More information about the mythtv-users mailing list