On 12/10/2014 10:01 AM, Alexandre Detiste wrote:
control: tags -1 fixed-upstream
Hi,
I'm still working on this last major bug of systemd-cron.
I thought it had been solved reusing the crontab binary from the cron
package - tldr please?
I came up with this setuid helper, that is called by crontab when needed:
https://github.com/systemd-cron/systemd-cron/blob/setuid/src/bin/crontab_setuid.c
I avoided the most obvious pitfalls: string format attacks,
tmp files/symlinks attacks (it uses stdin/stdout to pass crontab data);
and I made it as bare as possible.
Please review it
Alexandre
<annoying>
why a C file in bin/? :)
useradd(1) says username is <= 32 chars, so crontab[256] is ok.
fgets() with short buffers tested ok with glibc & musl, so buffer[512]
is ok.
</annoying>
Not checking writes to stdout is probably ok unless you're playing with
/dev/full or something like that.
The 'w' option should imho do the equivalent of
cat > $crontab.new \
&& (chmod,chown as appropriate?) \
&& mv $crontab.new $crontab
It should also check that fclose(file) succeeds (errors in stdio are
sticky: after the first error, anything else you do will report an error
until you clearerr()).
Rationale for both:
1.people fill /var sometimes
2. power failure at the wrong time should be as harmless as possible
(we've had a few here recently due to the rain).
Most importantly: if I understand correctly, the idea is that you have a
crontab in python which does its stuff as a normal user and does
privileged operations by calling the helper because python setuid is
troublesome; but if so, this program never tries to switch id!
(I'm not testing the package on my pc; give me a few hours and I'll dig
up the vm I set up for systemd-cron)
--
systemd-cron postinst script needs to do this too:
chown root:root /var/spool/cron/crontabs
chmod 770 /var/spool/cron/crontabs
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
