Your message dated Mon, 27 Jul 2020 23:23:04 +0200
with message-id <[email protected]>
and subject line Re: systemd-journald: user service logs are not available to 
normal users unless persistent Storage is used.
has caused the Debian Bug report #843310,
regarding systemd-journald: user service logs are not available to normal users 
unless persistent Storage is used.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
843310: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843310
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 232-1
Severity: normal

Dear systemd and journald maintainers,

User services generate output and that output is logged by the user's
systemd session manager. journalctl(1) says:

       All users are granted access to their private per-user journals.

However, this isn't the case for volatile logs -- it's only true if
/var/log/journal exists and is used by the journal daemon
(journal.conf has Storage= set to either "persistent" or "auto").  As
noted in systemd-journald(8), access to files in /var/log/journal is
controlled by filesystem permissions, and per-user journal files are
given an ACL that allows reading by the user in question.

But the files in /run/log/journal (including .) are owned
root:systemd-journal, and only have an acl permitting group reading by
group "adm".

if /var/log/journal doesn't exist, then the files in /run/log/journal
are named like:

    
/run/log/journal/6051cddb073148558d78ef88b325d68c/system@69e51cd1f22d4569aee1f96c1219d41d-00000000000008cc-0005409149915123.journal
    
/run/log/journal/6051cddb073148558d78ef88b325d68c/system@69e51cd1f22d4569aee1f96c1219d41d-0000000000000434-000540908e2a4975.journal

but /run/log/journal is removed once /var/log/journal exists, and
/var/log/journal files are named like this:

    /var/log/journal/6051cddb073148558d78ef88b325d68c/user-1000.journal
    /var/log/journal/6051cddb073148558d78ef88b325d68c/system.journal

Without /var/log/journal existing, with a user with no special
membership in adm or systemd-journal, i see no log info:

-----------
dkg@sid:~$ groups
dkg
dkg@sid:~$ journalctl --user-unit gpg-agent | tail
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
No journal files were opened due to insufficient permissions.
dkg@sid:~$ systemctl status --user gpg-agent | cat
● gpg-agent.service - GnuPG cryptographic agent and passphrase cache
   Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; static; vendor 
preset: enabled)
   Active: active (running) since Sat 2016-11-05 12:47:26 EDT; 18min ago
     Docs: man:gpg-agent(1)
 Main PID: 836 (gpg-agent)
   CGroup: /user.slice/user-1000.slice/[email protected]/gpg-agent.service
           └─836 /usr/bin/gpg-agent --supervised
dkg@sid:~$ 
-----------

If you want to try to replicate, this is with the stock gpg-agent
user service from the gnupg-agent package, version 2.1.15-8, with the
following command run in bash as root before regular user login:

    # systemctl --user --global enable gpg-agent{,-ssh,-extra,-browser}.socket

And the user has the following two lines in ~/.gnupg/gpg-agent.conf:

    debug-level guru
    debug-pinentry

-------

fwiw, strace can see journalctl trying to access files in /run/log
before i tries to look in /var/log/journal, but gets EACCESS
(Permission denied) errors (as one would expect from the permissions
on it).

Shouldn't systemd-journald manage its files in /run/log/journal with
the same approach and permissions that it uses for files in
/var/log/journal?

Regards,

        --dkg

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.115
ii  libacl1         2.2.52-3
ii  libapparmor1    2.10.95-5
ii  libaudit1       1:2.6.7-1
ii  libblkid1       2.28.2-1
ii  libc6           2.24-5
ii  libcap2         1:2.25-1
ii  libcryptsetup4  2:1.7.3-1
ii  libgcrypt20     1.7.3-2
ii  libgpg-error0   1.24-1
ii  libidn11        1.33-1
ii  libip4tc0       1.6.0-4
ii  libkmod2        23-1
ii  liblzma5        5.2.2-1.2
ii  libmount1       2.28.2-1
ii  libpam0g        1.1.8-3.3
ii  libseccomp2     2.3.1-2
ii  libselinux1     2.6-1
ii  libsystemd0     232-1
ii  mount           2.28.2-1
ii  util-linux      2.28.2-1

Versions of packages systemd recommends:
ii  dbus            1.10.12-1
ii  libpam-systemd  232-1

Versions of packages systemd suggests:
ii  policykit-1        0.105-17
pn  systemd-container  <none>
pn  systemd-ui         <none>

Versions of packages systemd is related to:
pn  dracut           <none>
ii  initramfs-tools  0.125
ii  udev             232-1

-- no debconf information

--- End Message ---
--- Begin Message ---
Version: 244.1-2

On Sat, 05 Nov 2016 15:16:08 -0400 Daniel Kahn Gillmor
<[email protected]> wrote:
> Package: systemd
> Version: 232-1
> Severity: normal
> 
> Dear systemd and journald maintainers,
> 
> User services generate output and that output is logged by the user's
> systemd session manager. journalctl(1) says:
> 
>        All users are granted access to their private per-user journals.
> 
> However, this isn't the case for volatile logs -- it's only true if
> /var/log/journal exists and is used by the journal daemon
> (journal.conf has Storage= set to either "persistent" or "auto").  As
> noted in systemd-journald(8), access to files in /var/log/journal is
> controlled by filesystem permissions, and per-user journal files are
> given an ACL that allows reading by the user in question.
> 
> But the files in /run/log/journal (including .) are owned
> root:systemd-journal, and only have an acl permitting group reading by
> group "adm".
> 
> if /var/log/journal doesn't exist, then the files in /run/log/journal
> are named like:
> 
>     
> /run/log/journal/6051cddb073148558d78ef88b325d68c/system@69e51cd1f22d4569aee1f96c1219d41d-00000000000008cc-0005409149915123.journal
>     
> /run/log/journal/6051cddb073148558d78ef88b325d68c/system@69e51cd1f22d4569aee1f96c1219d41d-0000000000000434-000540908e2a4975.journal
> 
> but /run/log/journal is removed once /var/log/journal exists, and
> /var/log/journal files are named like this:
> 
>     /var/log/journal/6051cddb073148558d78ef88b325d68c/user-1000.journal
>     /var/log/journal/6051cddb073148558d78ef88b325d68c/system.journal
> 
> Without /var/log/journal existing, with a user with no special
> membership in adm or systemd-journal, i see no log info:
> 
> -----------
> dkg@sid:~$ groups
> dkg
> dkg@sid:~$ journalctl --user-unit gpg-agent | tail
> Hint: You are currently not seeing messages from other users and the system.
>       Users in the 'systemd-journal' group can see all messages. Pass -q to
>       turn off this notice.
> No journal files were opened due to insufficient permissions.
> dkg@sid:~$ systemctl status --user gpg-agent | cat
> ● gpg-agent.service - GnuPG cryptographic agent and passphrase cache
>    Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; static; vendor 
> preset: enabled)
>    Active: active (running) since Sat 2016-11-05 12:47:26 EDT; 18min ago
>      Docs: man:gpg-agent(1)
>  Main PID: 836 (gpg-agent)
>    CGroup: /user.slice/user-1000.slice/[email protected]/gpg-agent.service
>            └─836 /usr/bin/gpg-agent --supervised
> dkg@sid:~$ 
> -----------
> 
> If you want to try to replicate, this is with the stock gpg-agent
> user service from the gnupg-agent package, version 2.1.15-8, with the
> following command run in bash as root before regular user login:
> 

I guess this issue has become moot as we now enable persistent storage
since 244.1-2. So closing accordingly.

Regards,
Michael

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---

Reply via email to