(sorry for the top posting, I'm using gmail's web client) The setfacl thing doesn't work because.... (suspense)... I tried it in a fresh sid install in a vm and setfacl was not installed.
If I were you I would use something like https://www.uninformativ.de/git/overqemu/file/README.html (customised a bit for your needs) to run this kind of experiments - start with a fresh install with nothing else installed, test your fixes in a temporary vm that's created cheaply; especially useful if someone ever says they only have the problem on some weird architecture ("it works on my laptop but not on my mips64 thingie"). If setfacl is what it takes, it will have to be added as a dependency - any reason why chown won't work? (chown is installed everywhere) Re users: no, user/group cron are nothing special, it's just a security measure - if your program doesn't need to be root the whole time, it's worth it to split it in a part that runs as some random unprivileged user that can do basically no harm. The openbsd folks have a few presentations on the subject (https://www.openbsd.org/events.html - I no longer remember which one made me understand the idea, sorry! look for "privilege separation" and then for some daemon that you care about - ntpd in my case http://www.openntpd.org/papers.html) Thank you for picking up the package btw - becoming a package maintainer is something I could never bring myself to do, greatly appreciated! Il giorno gio 16 giu 2022 alle ore 10:49 Georges Khaznadar <[email protected]> ha scritto: > > Hi Lorenzo, > > thank you for the bug report. > > I am learning to maintain bcron: this package was orphaned until two > days ago, and I am a recent adopter, willing to maintain it further. > > the directory /var/spool/cron/crontabs hosts crontabs for various users, > and the scripts found in every crontab are supposed to run with the > permissions of the related user, aren't they? > > When I tried to adapt bcron to use the package cron-daemon-common, in > order to give all packages which provide cron-daemon a chance to > compete, I saw that files under /var/spool/cron/crontabs where owned by > cron:cron, when managed by bcron (<< 0.11-12), unlike files managed by > cron-daemon-common, which are owner by <respective user>:crontab. > > At that time, I supposed that running every user script with the > permissions of the right user implied that user cron or group cron have > super priviledges, so the change would be harmless. > > Your bug report shows me that cron has no super priviledges. > > So there is something to fix. Please can you tell me wheter the > following commands can fix the issue, in your case ? > > # setfacl -m u:cron:rwx /var/spool/cron/crontabs > # setfacl -m g:cron:rwx /var/spool/cron/crontabs > # for f in /var/spool/cron/crontabs/*; do setfacl -m u:cron:rw $f; setfacl -m > g:cron:rw $f; done > > If those commands can fix the issue, I shall modify bcron's > post-installation script to fix the bug. > > Thank you in advance for your help. > > Best regards, Georges. > > Lorenzo Beretta a écrit : > > Package: bcron > > Version: 0.11-12 > > Severity: important > > > > Sorry for using gmail webmail - gmail decided I can't let "less secure > > apps" send mail on my behalf, I'm trying to figure out what can be > > done. > > > > Anyway, here's what I wanted reportbug to send... > > > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > From: Lorenzo Beretta <[email protected]> > > To: Debian Bug Tracking System <[email protected]> > > Subject: bcron-sched fails to start after latest update > > Message-ID: > > <165530519508.4489.146445291116667405.report...@dudu.homenet.telecomitalia.it> > > X-Mailer: reportbug 11.5.0devuan1 > > Date: Wed, 15 Jun 2022 16:59:55 +0200 > > > > Package: bcron > > Version: 0.11-12 > > Severity: important > > > > Dear Maintainer, > > > > right after the latest upgrade bcron stopped working: > > crontab says "bcrontab: Fatal: Could not read crontab", > > bcron-sched fails to start, svlogd says > > 2022-06-15_14:45:25.22147 bcron-sched: Starting > > 2022-06-15_14:45:25.22152 bcron-sched: Fatal: Could not open crontabs > > directory: Permission denied > > 2022-06-15_14:45:25.22168 bcron-exec: Waiting for remaining slots to > > complete > > > > According to strace bcron calls setuid(997) (ie "cron") > > and then it chdirs /var/spool/cron (OK) > > and THEN it tries to openat(AT_FDCWD, "crontabs", ...) => EACCES > > > > $ ls -ld /var/spool/cron/crontabs/ > > drwx-wx--T 2 root crontab 4096 Jun 15 16:51 /var/spool/cron/crontabs/ > > > > but the crontabs in there are owned by cron:cron. > > > > I'm using devuan, but the exact same bug happens in a sid virtual machine. > > > > That's all the info I have atm, good day. > > > > > > -- System Information: > > Debian Release: bookworm/sid > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.18.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_US:en > > Shell: /bin/sh linked to /bin/dash > > Init: runit (via /run/runit.stopit) > > LSM: AppArmor: enabled > > > > Versions of packages bcron depends on: > > ii cron-daemon-common 3.0pl1-144 > > ii daemon 0.8-1 > > ii init-system-helpers 1.63devuan1 > > ii libbg2 2.04+dfsg-2.1 > > ii libc6 2.33-7 > > ii runit-helper 2.13.1 > > ii sysuser-helper 1.3.7+really1.4.1 > > ii ucspi-unix 1.0-1 > > > > Versions of packages bcron recommends: > > ii dma [mail-transport-agent] 0.13-1+b1 > > ii runit 2.1.2-45 > > > > Versions of packages bcron suggests: > > ii anacron 2.3-32 > > ii runit-init 2.1.2-45 > > > > -- no debconf information > > -- > Georges KHAZNADAR et Jocelyne FOURNIER > 22 rue des mouettes, 59240 Dunkerque France. > Téléphone +33 (0)3 28 29 17 70 >
