Bug#767894: More permission issues
Package: systemd-cron Version: 1.3.1+ds1-1 Severity: minor Generally, crontabs are only visible by the owner. After #766053 gets fixed, the issue still remains in the sense that the generated units/timers (coming from crontabs) have root:root 644 permissions, which are readable by everyone. I've seen 'journalctl' actually uses ACLs, so maybe it's safe to use ACLs by default now since systemd is a dependency? In that case, I would chmod the user-generated units/timers to 640, and add an explicit ACL for 400 user:root (the same is done by journald when using the 'login' splitting method - so I'm not using a new method here). This prevents the file to be modified by the user, while still giving him r/o access. Not that we strictly need it anyway: 640 root:root would be enough. The description itself contains a copy of the crontab line. I would actually prefer the normal description to be just crontab-user:line (easier to debug than matching text). It's less noisy in the unit list, and also easier to grep for. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd-cron depends on: ii init-system-helpers 1.21 ii python 2.7.8-2 pn python:any none ii systemd-sysv 215-5+b1 systemd-cron recommends no packages. systemd-cron suggests no packages. -- debsums errors found: debsums: changed file /lib/systemd/system-generators/systemd-crontab-generator (from systemd-cron package) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#767894: More permission issues
The current status of /var/spool/cron/crontabs is undetermined ... users either inherit what was setup up by the previosu cron daemon or get a vanilla 0755 folder on fresh install. e.g.: http://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/tree/debian/postinst Having crontab translate on the fly user crontabs into ~/.config/systemd/user service timers (systemd --user) would avoid all these security problems. This need a refactor of the generator to turn it into a module that can be called from crontab. crontab -l -e would just parse back the Description=[cron] records ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#767894: More permission issues
On 11/03/2014 12:43 PM, Alexandre Detiste wrote: The current status of /var/spool/cron/crontabs is undetermined ... users either inherit what was setup up by the previosu cron daemon or get a vanilla 0755 folder on fresh install. e.g.: http://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/tree/debian/postinst Having crontab translate on the fly user crontabs into ~/.config/systemd/user service timers (systemd --user) would avoid all these security problems. This need a refactor of the generator to turn it into a module that can be called from crontab. crontab -l -e would just parse back the Description=[cron] records FIY, systemd does not currently save timer stamps when run under --user: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767086q I would recommend waiting for this to be fixed before moving jobs to ~/.config/systemd/user. After this is fixed, then yes, it would actually be much better. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#767894: More permission issues
On 11/03/2014 12:48 PM, Yuri D'Elia wrote: e.g.: http://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/tree/debian/postinst Having crontab translate on the fly user crontabs into ~/.config/systemd/user service timers (systemd --user) would avoid all these security problems. This need a refactor of the generator to turn it into a module that can be called from crontab. crontab -l -e would just parse back the Description=[cron] records FIY, systemd does not currently save timer stamps when run under --user: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767086q I would recommend waiting for this to be fixed before moving jobs to ~/.config/systemd/user. After this is fixed, then yes, it would actually be much better. Humm, although moving the jobs to the systemd --user instance would require the user to: 1: have lingering enabled (we could check for this in crontab and emit a warning maybe?) 2: login at least once(!) to start the user session. #2 is a deal-breaker. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#767893: systemd cannot mount zfs filesystems from fstab
It seems like it is unable to mount a zfs volume given in fstab during boot. Strangely the presence of such an entry in fstab also seems to cause the password entry problem. With no zfs in fstab I can enter the passwords and the zfs volumes with non legacy mount points mount ok. It sounds like maybe I need to try a Plymouth theme as well as just plymouth as I do not get a graphical start screen. However if a fix is coming for systemd maybe I should wait for that to see if it clears it up. On November 3, 2014 8:09:44 AM EST, Zbigniew Jędrzejewski-Szmek zjedr...@gmu.edu wrote: On Mon, Nov 03, 2014 at 05:51:57AM -0500, John Holland wrote: I created luks volumes, installed zfsonlinux.org packages, created a zpool out of the luks volumes. When ZFS is managing the mounting of the fs's it works. If I put a zfs filesystem in /etc/fstab the prompts to enter passwords for the luks volumes during boot are mixed in with output. So actually its not the ZFS volumes, but simply the luks unlocking that is the problem? You say that the prompts are mixed with output, but do things work if you type in the password blind? You can either wait until systemd-217 (which fixes the overlapping output) or install plymouth (which provides a graphical prompt which is not interrupted by text output). ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#767893: systemd cannot mount zfs filesystems from fstab
Am 03.11.2014 um 15:06 schrieb John Holland: It seems like it is unable to mount a zfs volume given in fstab during boot. Strangely the presence of such an entry in fstab also seems to cause the password entry problem. With no zfs in fstab I can enter the passwords and the zfs volumes with non legacy mount points mount ok. It sounds like maybe I need to try a Plymouth theme as well as just plymouth as I do not get a graphical start screen. However if a fix is coming for systemd maybe I should wait for that to see if it clears it up. On November 3, 2014 8:09:44 AM EST, Zbigniew Jędrzejewski-Szmek zjedr...@gmu.edu wrote: On Mon, Nov 03, 2014 at 05:51:57AM -0500, John Holland wrote: I created luks volumes, installed zfsonlinux.org packages, created a zpool out of the luks volumes. When ZFS is managing the mounting of the fs's it works. If I put a zfs filesystem in /etc/fstab the prompts to enter passwords for the luks volumes during boot are mixed in with output. So actually its not the ZFS volumes, but simply the luks unlocking that is the problem? You say that the prompts are mixed with output, but do things work if you type in the password blind? You can either wait until systemd-217 (which fixes the overlapping output) or install plymouth (which provides a graphical prompt which is not interrupted by text output). http://changelog.complete.org/archives/9241-update-on-the-systemd-issue might be relevant for you. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
[bts-link] source package systemd
# # bts-link upstream status pull for source package systemd # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #766413 (http://bugs.debian.org/766413) # Bug title: /lib/systemd/systemd-resolved: domain and search lines missing from resolv.conf # * https://bugs.freedesktop.org/show_bug.cgi?id=85397 # * remote status changed: NEW - NEEDINFO usertags 766413 - status-NEW usertags 766413 + status-NEEDINFO thanks ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: found 767951 in 1.3.1+ds1-2
Processing commands for cont...@bugs.debian.org: found 767951 1.3.1+ds1-2 Bug #767951 [systemd-cron] systemd-cron: crontab -r user will remove root crontab Marked as found in versions systemd-cron/1.3.1+ds1-2. thanks Stopping processing here. Please contact me if you need assistance. -- 767951: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767951 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: notfound 767951 in 1.3.4-1
Processing commands for cont...@bugs.debian.org: notfound 767951 1.3.4-1 Bug #767951 [systemd-cron] systemd-cron: crontab -r user will remove root crontab There is no source info for the package 'systemd-cron' at version '1.3.4-1' with architecture '' Unable to make a source version for version '1.3.4-1' No longer marked as found in versions 1.3.4-1. thanks Stopping processing here. Please contact me if you need assistance. -- 767951: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767951 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
systemd-cron 1.3.1+ds1-2 MIGRATED to testing
FYI: The status of the systemd-cron source package in Debian's testing distribution has changed. Previous version: 1.3.1+ds1-1 Current version: 1.3.1+ds1-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Hello, Am Samstag, den 11. Oktober schrieb Michael Biebl: could you please remove your local service file again, add systemd.log_level=debug to the kernel command line, enable verbose udev debug logging via /etc/udev/udev.conf and then after a reboot, attach the output of journalctl -alb My little script no longer worked: the system hangs at trying to mount sdb and gives up after 1:30 min. But… Inbetween I found that the systems boots if I deinstall lvm2. So there seems to be some interaction between lvm2 and btrfs udev-rules or systemd-scripts. I attached the compressed log. This was with my script and lvm2 installed and failed. MfG bmg -- „Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!“ | berbe...@fmi.uni-passau.de (SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic journalctl-alb.log.xz Description: application/xz ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#765870: systemd-logind brings system to knees with RAM consumption
Am 18.10.2014 um 21:49 schrieb John Goerzen: Package: systemd Version: 215-5+b1 Severity: grave Justification: renders package unusable On investigating why my 8GB system, which was suddenly running extremely slow and maxed out on swap, I discovered numerous systemd-logind processes hogging RAM. Specifically, 41 processes using 4278148KB (or roughly 4GB) of RAM. Here is some output from top: As John told me on IRC: He is running systemd-logind under systemd-shim on this particular system. On other systems, where systemd is PID 1 he does not experience this issue. I told him to find out the current running systemd-logind process which owns the org.freedesktop.login1 D-Bus name via dbus-send --system --dest=org.freedesktop.DBus --print-reply /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID string:org.freedesktop.login1 and monitor that process via strace while periodically checking with the above command, when logind drops off the bus. So we can eventually see from the strace what happens at that time. Unfortunately, when stracing the process, John is no longer able to reproduce the issue, as he told on IRC. John, to narrow down the problem, could you please boot with init=/bin/systemd to verify if this issue is indeed related to systemd-shim. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#765870: systemd-logind brings system to knees with RAM consumption
This is indeed an accurate summary. One more data point - I rebooted without that change, and the problem indeed persists. I will try with it, but it will take a bit of work to make it ready. Give me a day or two. John ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#767893: systemd cannot mount zfs filesystems from fstab
On Mon, Nov 03, 2014 at 03:36:49PM +0100, Michael Biebl wrote: http://changelog.complete.org/archives/9241-update-on-the-systemd-issue might be relevant for you. Yeah, this might be relevant. When I read that ZFS has init scripts with carefully-planned dependencies, I shudder. They clearly have a bug with refusing to mount over non-empty directories, this seems like something likely to bite people all the time. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
