Bug#1012852: bcron-sched fails to start
Hi Lorenzo,
Lorenzo Beretta a écrit :
> [...]
> 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 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)
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.
> 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 the information. Do you know whether the usage of bcron is
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.
>
> 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
> 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 :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
> > > To: Debian Bug Tracking System
> > > 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
> > >
> >
Bug#1012852: bcron-sched fails to start
(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
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 :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
> > To: Debian Bug Tracking System
> > 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 (c
Bug#1012852: bcron-sched fails to start
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 :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 > To: Debian Bug Tracking System > 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 libc62.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 signature.asc Description: PGP signature
Bug#1012852: bcron-sched fails to start
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 To: Debian Bug Tracking System 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 libc62.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
