I agree. It feels like a defeat, using a set-gid program, but under
the current conditions, no hard-link games are acceptable.
The set-gidness is needed only to create the queue file, and
to delete it should the process receive a signal.
Wietse
Perry E. Metzger:
>
> Wietse Venema <wietseat_private> writes:
> > I see two directions for Postfix evolution: 1) maintain the present
> > world-writable maildrop and unprivileged posting agent and 2) use
> > a protected directory and a set-gid posting agent (set-uid seems
> > to have no obvious advantage here). Is it feasible to keep maildrop
> > queue file names secret, and are the other attacks indeed mere
> > annoyances? Is it feasible to write secure set-gid programs that
> > are not only secure today, but that will be secure on tomorrow's
> > UNIX systems as well?
>
> The only thing that Postfix really needs is a tiny sgid program (about
> 20 lines in length) that reads a mail message on stdin and writes it
> out to a file in the mail drop directory -- and *only* into the mail
> drop directory, and *only* if the file doesn't exist yet (i.e. open
> with O_CREAT). The gid would be unique to the mail drop directory --
> breaking the ID would at best leave you with the ability to do the
> sorts of things you can do right now (i.e. nothing particularly
> mean). Because the program would be very small, it could be well
> scrutinized. Because it would be a gateway to microscopic privileges,
> it would be not-so-bad if it were broken.
>
> With this out of the way, Postfix would lose some edge condition
> problems it has now because of the world writable spool dir. This
> would not be a perfect fix, but it would be reasonably pragmatic.
>
> Perry
>
>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:26:10 PDT