On 06/11/2010 07:32 PM, vladz wrote: > 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.
Good point. >> 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). Indeed, I was wrong here. >> 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. We may be misunderstanding us here, so to clarify my point: * * * * * cat >/tmp/foo%this is input for cat will run /bin/cat and write "this is input for cat" to cat's stdin (this can be used for program's that expect some kind of input). Say you want to run a program that requires those chars as input at some point. If we refuse '\r' and '\b', then there would be no way to feed those to that program. Note that I'm speaking theoretically here; I haven't tested this. >> 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: I need to give this some more thought. If my concern regarding % above is correct, then a solution must be found to accommodate both problems. If my concern is wrong, I will apply your patch. Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
