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 <vc.net.loreb@gmail.com> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: bcron-sched fails to start after latest update Message-ID: <165530519508.4489.146445291116667405.reportbug@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.
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 :
(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 <georges.khaznadar@orange.fr> ha scritto:
Hi Lorenzo,
Lorenzo Beretta a écrit :
I shall probably not modify the traditional permission scheme which is
set up by the majority of people using a con-daemon service.
So, the permissions of files under /var/spool/cron/crontabs will keep
being ruled by user ${USER} and group crontab.
setfacl is a command which allows one to establish access control lists
(acl), i.e. additional users or groups, each one with his particular
permissions, enhancing the "ugo" traditional categories in Un*x
filesystems. So, a file can be owned, for example, by user foo and by
user cron.
majoritary among openbsd folks?
So far, I could see that the name "bcron" would mean "better cron" or
"Bruce Guenter's cron", I read the claim that bcron would be more
secuire because tasks are split into separate processes, which were
developed with security in mind.
I suppose that this claim means at least: security in Bruce Guenter's mind.
I tried to seek more information about the grounds of this belief in
security, and found not document explaining the internals of bcron. So I
suppose that people are trusting Bruce Guenter because of his
reputation.
- Unfortunately there were no updates at https://untroubled.org/bcron/
for seven years now.
- Unfortunately, I did not find meta-information to help one to
understand bcron's internals. The source code is scarcely commented,
and the main figure is difficult to grasp. Please do you know any
pointer to valuable information about it?
I shall add a dependency on package acl, and implement the tricks I
suggested in my previous e-mail, thank you for your report!
Best regards, Georges.
We believe that the bug you reported is fixed in the latest version of
bcron, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1012852@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Georges Khaznadar <georgesk@debian.org> (supplier of updated bcron package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 17 Jun 2022 15:55:54 +0200
Source: bcron
Architecture: source
Version: 0.11-14
Distribution: unstable
Urgency: medium
Maintainer: Georges Khaznadar <georgesk@debian.org>
Changed-By: Georges Khaznadar <georgesk@debian.org>
Closes: 1012852
Changes:
bcron (0.11-14) unstable; urgency=medium
.
* manage access to crontabs for user and group cron, with ACLs:
closes: #1012852
* added a pre-dependency on package acl
Checksums-Sha1:
ce5314fd43b60e9029f91b99eff696a017cc5603 2030 bcron_0.11-14.dsc
79fe7e5ab082ba075ef6ed455ade11c980aaea0d 18084 bcron_0.11-14.debian.tar.xz
7003536ec84c47fe4e6b3b368a5dc033382eae7e 7108 bcron_0.11-14_source.buildinfo
Checksums-Sha256:
a2306f040773bffe2cb57023fa28f10f916d2538c33497825af130ed4981e12a 2030 bcron_0.11-14.dsc
a2deaa4696b2d4c1a834a9bf85c55448cceb3c9f195e807b1db5bd56155be22c 18084 bcron_0.11-14.debian.tar.xz
efa164e941cf4d161f4bbadfcf4ffeea170d0d479e34e27b91f2c8877b8c360b 7108 bcron_0.11-14_source.buildinfo
Files:
88aba71f685c556a3c0b44299312d34a 2030 admin optional bcron_0.11-14.dsc
73f763cc7497814ff3e157e09f6bde18 18084 admin optional bcron_0.11-14.debian.tar.xz
877badc691dc4627bc59ba99358ac220 7108 admin optional bcron_0.11-14_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJIBAEBCAAyFiEEM0CzZP9nFT+3zK6FHCgWkHE2rjkFAmKsiJ0UHGdlb3JnZXNr
QGRlYmlhbi5vcmcACgkQHCgWkHE2rjnluxAAkhZI+ho/lgwHNpBCXGkrBYGeSXQl
j0tDm/u0VWEi8eER7f9NutV0D2gEE0OEvVSOLXfHnvGefSmddxTJszhAnPKjxVBy
EpbVsiLrz+WkunADnc9cwNtJG/9h9Y9bi7hVAHzc7L1kp58M/Jox7y7r/ziULIuk
8tTJ/kRhwmXGk9ESlxQ2G8WClGOpKzUHwiPHuqkXyDYyyFllJ8Wp2SXX5BNOQ843
kZxUy/6D1VDd0b2xUATOzn6j9hNPmhbVnUq1e+dzaZvR1kuyOSTKh8gcdm5FKLCZ
Fcz6eko3dZHuzyIUyGyI9ok3201kLHu7QKtxgazfMQOVeQib5WqxZ7Dhhg/1pVSa
YLOw6Xe+gDqIMk8MBYRuGoXgxPlDselz1H+I4pU3UoJAJGAdlnHjjMd23tw7iDC6
YE3ChFCAIH91uCfTVLsl7sDQsQk4gItUTGnxtSYmfTNyAb7CQjVrUNtkWcjOUStg
N5xFKG758txHERtfsXs4oEDMs5K0fjOT5fZkAXtPLdSPh/Ut+Iel3VAkmPX4W3X7
20I9I4Hn2FImTFH5pMTjrARboIMxC2xPd+e+mPRDZ+H5cZyK7fehwnFFlCawIk5/
nY+WdewJkR7kL+Wm+2E+Kxku/7kcgT4Ig5gvCcqnmhAMvb3VfsLw4wbDSJqtQk5b
ktaRofjok3PdMxc=
=dxSx
-----END PGP SIGNATURE-----