Version: 9.4.58-2 Severity: normal Subject: jetty9: LogsDirectory= changes /var/log/jetty9 group from adm to jetty The package currently uses two conflicting mechanisms to manage the ownership of the log directory. The tmpfiles configuration installs the directory as: ``` d /var/log/jetty9 0750 jetty adm Z /var/log/jetty9 - jetty adm ``` which clearly specifies that the directory group should be "adm". However, the systemd service contains: ``` User=jetty Group=jetty LogsDirectory=jetty9 ``` According to the systemd.exec(5) documentation, LogsDirectory= ensures that the innermost directory is owned by the User= and Group= configured for the service. As a result, when the service starts, systemd changes the ownership of: ``` /var/log/jetty9 ``` from: ``` jetty:adm ``` to: ``` jetty:jetty ``` The package previously managed directory ownership in postinst, but starting with version 9.4.58-2 this logic has been migrated to systemd-tmpfiles while LogsDirectory= has been kept unchanged. The packaging therefore contains two contradictory ownership definitions for the same directory: * debian/jetty9.tmpfiles expects: jetty:adm * debian/jetty9.service (via LogsDirectory=) enforces: jetty:jetty I could not find any packaging logic that restores the "adm" group after the service starts: * postinst no longer changes ownership of /var/log/jetty9; * no ExecStartPre= hook performs a corrective chown; * no ACLs are installed; * no other packaging scripts modify the directory ownership. Therefore, unless systemd has changed the semantics of LogsDirectory=, starting the service will overwrite the ownership established by tmpfiles.d. I believe the package should use only one ownership mechanism, or both mechanisms should agree on the expected ownership. Possible fixes include either: * changing the tmpfiles entry to use group "jetty" if that is the intended ownership; or * avoiding LogsDirectory= if the intended group is "adm". The current packaging is internally inconsistent and causes the configured ownership of /var/log/jetty9 to change depending on whether tmpfiles or systemd processed the directory most recently.
I performed an additional runtime verification of this issue using the current 9.4.58-2 packaging. Although my test machine is running Ubuntu 26.04, I temporarily upgraded only the Jetty packages (`jetty9`, `libjetty9-java`, and `libjetty9-extra-java`) to version **9.4.58-2**, which uses the same packaging as the current Debian unstable/testing package. The result is exactly the same as reported originally. After reboot: ``` drwxr-x--- 2 jetty jetty ... /var/log/jetty9 ``` The installed service configuration confirms that the service is running with: ``` LogsDirectory=jetty9 User=jetty Group=jetty ``` and rsyslog reports: ``` file '/var/log/jetty9/jetty-console.log': open error: Permission denied ``` I also verified that the installed tmpfiles configuration is: ``` d /var/log/jetty9 0750 jetty adm Z /var/log/jetty9 - jetty adm ``` Therefore, even after the migration from maintainer-script ownership management to `systemd-tmpfiles`, the issue remains unchanged. The observed runtime behavior matches the packaging: * `systemd` creates and/or reassigns `/var/log/jetty9` to `jetty:jetty` because of `LogsDirectory=jetty9`; * `rsyslog` runs as the `syslog` user and therefore cannot create `/var/log/jetty9/jetty-console.log`. This confirms that the problem is still reproducible with the current 9.4.58-2 packaging. that the ownership
I have found an additional packaging issue related to the permissions used for the Jetty log directory and log rotation. ### 1. `/var/log/jetty9` should be owned by `jetty:adm` with mode `0770` Even if the ownership problem caused by `LogsDirectory=` is addressed, the directory permissions themselves are still insufficient for the intended logging design. `rsyslog` runs as: ``` User: syslog Group: syslog Supplementary groups: adm ``` Therefore it does not need to become the owner of `/var/log/jetty9`, but it **does** require write permission through the `adm` group in order to create new log files. With the current packaging, the directory eventually becomes owned by `jetty:jetty` with mode `0750`, which completely prevents `rsyslog` from creating `jetty-console.log`. Even if the ownership is corrected back to `jetty:adm`, mode `0750` still leaves the group without write permission. For the logging configuration installed by the package to work correctly, the directory needs to be writable by members of the `adm` group. In practice this means ownership `jetty:adm` together with mode `0770`. ### 2. The logrotate configuration recreates the file with insufficient permissions There is another independent issue in the package's logrotate configuration. The installed configuration currently contains: ``` create 640 jetty adm ``` After every rotation, logrotate recreates `jetty-console.log` as: ``` -rw-r----- jetty:adm ``` At this point `rsyslog` is no longer the file owner, and accesses the file through its supplementary `adm` group membership. However, mode `0640` grants the group only read permission, so `rsyslog` can no longer append new log messages after the file has been recreated. Changing the directory permissions alone is therefore not sufficient to fix the problem. The recreated log file also needs to remain writable by the `adm` group. Using mode `0660` instead of `0640` preserves write access for `rsyslog` after every log rotation. I verified this locally by changing the installed logrotate configuration from: ``` create 640 jetty adm ``` to: ``` create 660 jetty adm ``` After this change, the recreated log file remained writable by `rsyslog`, and logging continued normally after rotation.
I found one more packaging issue that becomes visible once the log directory permissions are corrected. After changing `/var/log/jetty9` to the permissions required for rsyslog (`0770 jetty:adm`), the package's current logrotate configuration no longer works. Running: ``` sudo logrotate -f /etc/logrotate.d/jetty9 ``` fails with: ``` error: skipping "/var/log/jetty9/jetty-console.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation. ``` This is expected behaviour of logrotate. When the parent directory is writable by a non-root group, logrotate refuses to operate unless an explicit `su` directive is configured. After adding: ``` su jetty adm ``` to the logrotate configuration, rotation succeeds normally. Combined with the previously reported issue regarding: ``` create 640 jetty adm ``` (which should be `create 660 jetty adm` so that rsyslog can continue writing after rotation), the package's logrotate configuration also requires the appropriate `su` directive. In other words, if the package is fixed by making `/var/log/jetty9` writable by the `adm` group (which is necessary for rsyslog), the logrotate configuration must be updated accordingly as well. Otherwise log rotation will fail with the "parent directory has insecure permissions" error. it create configuration. can fix