[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: crontab and editors (was Re: Editor Priorities)



On Mon, May 13, 2002 at 09:22:05AM -0500, Steve Greenland wrote:
> On 13-May-02, 08:59 (CDT), Michael Stone <mstone@debian.org> wrote: 
> > You've completely missed the point of the patch. :) The goal is to allow
> > the user to edit the crontab file but not to turn it into a symlink or
> > somesuch.
> 
> I think you've missed the point. The point is to allow the user to edit
> the crontab file w/o some *other* user changing it to a symlink or
> otherwise screwing with it.

Nope. That's one problem. The other problem is the user attacking
crontab to escalate his own privilage. There are two opens--the user's
open of crontab's tempfile, and crontab's subsequent open of the same
file--and each needs to be protected.

>  If the user doesn't have write permission to
> the directory, the editor can't write a new copy of the file, which is
> exactly what people were complaining about.

No, people are complaining that the user *can* write a new copy of the
file, but crontab will silently ignore it. The real goal is to modify
the file, and have crontab read the modifications. The "write a new
copy" failure is a side-effect of the original fix, not a fundamental
requirement. This other (mkdir) approach is also not a fundamental
requirement, but it's minimally-intrusive. In truth crontab should
already be able to handle the case of reading an untrusted file (we
hope) because it does exactly that with "crontab filename" syntax--so it
should be completely possible to have crontab generate a safe tmpfile in
an arbitrary location, let the user edit the file, and do the equivalent
of "crontab tmpfilename"--there should only be one version of this code
in the source.  It might even be as simple as doing an fstat after the
reopen to make sure that the new file is owned by the user--but you'll
need to check the code to make sure the file is only opened once, etc.
The mkdir hack is merely quick fix to both the file creation and the
reopen problems--a good complete fix requires a closer look at &
discussion of the code, and you already vetoed that. :) (Said discussion
would likely be heavy on criticism.)

> > Try mkdir with permission mask 0711. 
> 
> Doesn't work.

Doesn't work for what? To edit a file the user should only need
permission *on the file*. Even editors that normally copy & rename
should notice when they have write permission on the file but not the
directory and act accordingly. (Tested with the small selection of
editors I have on hand; I'd really like to know which editors can't
handle that so bugs can be filed.)

-- 
Mike Stone


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: