Re: crontab and editors (was Re: Editor Priorities)
On Mon, May 13, 2002 at 09:24:12AM -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. 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. If the only person with r/w
> access to the directory is the user herself, what can happen? (Serious
> question, but I don't see it...)
I think you've missed half of the point. The point is to allow the user to
edit the crontab without allowing *anyone* to do *anything* untoward. This
means both protecting the user from other users, and protecting the
superuser from the user.
After the edit is complete, crontab (the privileged parent process) reads
the resulting file in order to write it into the crontabs directory. The
point is to avoid letting users trick crontab into reading arbitrary files
and writing them into the user's crontab, where the user can then read them.
The easiest thing to read this way would be other user's crontabs, including
root (which should be private), but anything that will escape the crontab
parser should work.
Some (most old) crontabs will even reveal chunks of any target file
whatsoever by issuing parse errors, making it easy to read /etc/shadow.
A possible alternate solution could be to have crontab read a pipe from the
child with the edited data. That way, the file would be read under the
user's UID, and no filesystem tricks would come into play. But you would
need to carefully consider all of the cases handled by the current
implementation before making such a change.
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: