[292] in linux-security and linux-alert archive
Re: YAWTCQ
daemon@ATHENA.MIT.EDU (Zefram)
Wed Jul 19 18:18:04 1995
From: Zefram <A.Main@dcs.warwick.ac.uk>
To: aleph1@dfw.net (Aleph One)
Date: Wed, 19 Jul 1995 18:52:11 +0100 (BST)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.SUN.3.90.950718163809.7449F-100000@dfw.net> from "Aleph One" at Jul 18, 95 04:38:41 pm
>Yet Another Way To Cheat Quotas
"Yet Another"? Being new to this list, I'd like to know what people
have come up with in the past. Is there an archive of the list?
[mod: The list is archived on http://www.sonic.net/hypermail/security
and ftp://linux.nrao.edu/pub/linux/security/list-archive. --okir]
>Background: Crond keeps the users crontabs under /var/spool/cron/crontabs.
>They are owned by root. Dont ask me way but I recall it has something to
>do with some security issue. Anyway...
Probably to stop anyone giving someone else a crontab. The directory
is root-only writable, crontab is setuid root. But there's no reason
it couldn't chown it. Curiously, at jobs *are* owned by the user
(otherwise crond wouldn't know who to execute them as), and it is
possible to edit them, and this does not pose any serious security
threat that I am aware of. It's even safe on systems where anyone can
chown their files to anyone, as the at job must have the setuid bit set
in order to be executed.
>crontab bighuge.tgz
>rm bighuge.tgz
>
>to recover:
>
>crontab -l > bighuge.tgz
>
>the crond man page sees it will onlie accept files with lines not longer
>then 1024 and no more then 256 lines. This gives you around 256K.
You'd have to encode the file into a legal crontab file, which reduces
this number somewhat. Anyway, who has quotas on /var?
-zefram
