On Fri, Jun 11, 2010 at 06:30:29PM +0200, Christian Kastner wrote: > I may be wrong, but I consider this only a minor problem.
Yes it is. > 1) the job is still logged to syslog > 2) the user does not have elevated permissions Right, I was just thinking of someone who want to keep the control over a shell account. Backdoor command would still run even if real user has changed is password. > 3) I doubt a sysadmin would check user crontabs with crontab -l Then, what is the "-u" option for, since only root can use it ? I may be wrong but what are the other ways for a sysadmin to check users crontabs ? Sysadmin can "cat" the crontabs files (/var/spool/cron/crontabs/<user>) but the result will be the same (carriage return will be displayed and sysadmin won't see any hidden tasks). > Your solution would probably screw with stdin piping to the executed > command (see crontab(5), "sixth field", percent sign). Executed commands > may need these characters. I don't think so, the patch only check characters and the percent sign '%' (char 0x25) is different than carriage return '\r' (0x0d) or backspace '\b' (0x08). Anyway, I stay open to all suggestions. > The solution I have in mind is to simply fix the output of crontab -l. Ok but the "problem" (again: not a real problem) still remains if we display the crontab file with other tools that prints control characters (like cat, grep, ...). The only ways to see hidden tasks (except syslog) are: - to edit crontab (but it depends on the editor, I mean "ed" will fail). - display crontab with hexdump: "crontab -l | hexdump -C". Best regards, Vlad. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
