[Samba] 'Permission denied' Journal entries for '/var/log/samba/log.rpcd_classic'

[Friedrich Romstedt]

Hi Rowland,

Am Mo., 8. Jan. 2024 um 12:18 Uhr schrieb Friedrich Romstedt
<friedrichromstedt at gmail.com>:
>
> The reason for this question is output in the systemd Journal of the
> server machine, consisting of two lines like the following (separated
> here by a blank line):
>
>
> [2024/01/08 10:34:11.358889,  0] ../../lib/util/debug.c:1264(reopen_one_log)
>
> reopen_one_log: Unable to open new log file
> '/var/log/samba/log.rpcd_classic': Permission denied
>
> [...]
>
> 1.  When I 'chown' the mentioned log file to the samba user I am
> authenticating as, the error disappears.

It is indeed fairly obvious, that the process which is attempting to
write to '/var/log/samba/log.rpcd_classic' is probably belonging to
the nonprivileged used, just as you said. This is the less challenging
observation. However, I did not find a way to solve the problem
arising from this situation, this is why I am writing to the list in
the first place.

On my box, the permissions for '/var/log/samba/' are 'root:root 755',
those for the files within that directory all 'root:root 644'. I
didn't tinker around with these.

It would make the error message most probably disappear when I would
make the log files world-writable. However, this would not appear to
me to be a real solution.

What are the permission bits for the log files within
'/var/log/samba/' on Debian?

I can guess two approaches here: 1) Making smbd prevent from giving up
its 'root' privilege, or 2) Finding a way to receive the logs without
rw access to log files for the unprivileged user.

However, for neither of both ideas I could find a way to go studying
them. This is why I'm writing. I hope there is some third way emerging
from our discussion.

For instance, I do not understand why 'logging = systemd file at 0'
yields the error message reported on in the beginning, while just
'logging = file at 0' makes the error not pop up. I would expect that
file 'file at 0' prevents log file writing in both cases.

The second approach I reported on, using '%u' or '%U', pointing to the
option to open only part of the log files for 'world' to be writable,
also didn't succeed, because '%U' evaluated to the empty string for
the root master process (effectively writing to a dot-file '.log' when
'%U.log' was requested), and '%u' just wasn't substituted. There might
be room for improvement in this direction, however I do not know which
steps to take next.

Thank you so far for your reply!

Looking forward,
Friedrich


P.S.: 'apparmor' is not installed on my system