Hi Robert! Yes, I know that cron is the most do not upgradable daemon in any unix system (so in FreeBSD cron didn't get opportunity to include another cron's configs, I've tried to send patch for add this, but in FreeBSD community I got refusing). I think that we have to remember the old classical software and try to upgrade it. And any big upgrade is growing from one small patch. May be it can bring some bugs in feature, but it's normal - only dead software hasn't bugs:) Many Debian's users are trying to find variants for change mail's header, but I think it isn't correct. What we can break in this case? Is a buffer overflow? I try to use function with limited length for this. Yes, user can input some incorrect data for mail's subject, but it transfer via cron to exec call, and I think is the most problem that can be - is a crash of the mail program.
Please correct me if I wrong --- Site Reliability Engineer Stan E. Putrya /"\ \ / ASCII Ribbon Campaign X against HTML email & vCards / \ чт, 17 дек. 2015 г. в 21:25, Robert Edmonds <[email protected]>: > Stanislav Zaharov wrote: > > Hello everybody! > > I've added new environment support to vixie-cron which is used by default > > cron in Debian. This environment is adding oppotunity to set mail subject > > for cron's report. It looks like this: > > MAILSUBJECT="CRON at the %hostname% (fqdn: %fqdn%): User %user% ran > command > > %cmd% which was executed with status %status%. Cron fork status: > > %forkstatus%" > > * * * * * root echo test > > > > It can be useful for many users. I've attached the patch for vixie cron. > > Could the patch be included to Debian release? > > Hi, Stan: > > Have you tried getting your patch merged upstream? (Just kidding, it > looks like Debian hasn't pulled a new upstream release of cron in about > 22 years, and new upstream releases are... infrequent.) > > More seriously, any C code that manipulates strings should be heavily > scrutinized, especially in a security sensitive daemon like cron, which > has had a history of security vulnerabilities, some of which were > introduced by later patches to the original code. > > There are static analyzers that can help with this, e.g. Clang's > scan-build (free), and Coverity (non-free). > > But, maybe it would be better to freeze the user-facing functionality of > a venerable tool like cron? This seems like kind of a disruptive > change. > > -- > Robert Edmonds > [email protected] > >
