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
> <georges.khazna...@orange.fr> 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 <vc.net.lo...@gmail.com>
> > > To: Debian Bug Tracking System <sub...@bugs.debian.org>
> > > 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
> >
--
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
