DragonFly kernel List (threaded) for 2008-06
DragonFly BSD
DragonFly kernel List (threaded) for 2008-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: GSoC 2008 dma enhancements

From: Simon corecode Schubert <corecode@xxxxxxxxxxxx>
Date: Tue, 10 Jun 2008 16:22:48 +0200

+++ Max Lindner [10/06/08 13:27 +0200]:
> Seems that the general tenor goes to a separate utility/helper
> application with suid-bit set which takes over the steps where
> root-access is compulsory. I will take a look at qmail which seems to
> have a similar design (as I read in the other dma thread which came up
> last week).

I think a helper process is better than a daemon constantly running.
However, I fear that it might be hard for the helper to verify that it has
been called by a valid dma process/binary.  One of course could be "mail"
group membership.  Maybe having dma fork() instantly, drop root in the "main"
part and have the child wait for instructions could be better, who knows.
Then it would at least be self-contained.

> But I need some input if the ~/.forward file is considered as strictly
> private and its contents should not be revealed under no
> circumstances.

I don't really think so.

> With this design one can strace/debug the process
> running and see the contents of another users .forward file.

Well, just disable it :)  You can't strace setgid/setuid binaries, so the
user won't have root/mail access.

> In my
> understanding there is nothing bad about revealing the contents of the
> ~/.forward file to other users. If someone wants to hide his extern
> final recipient-email-address, he can use an freemail account or
> something like this as a redirect service but I can't think about a
> scenario where this should be neccessary.

I don't want to speculate about this.  Maybe there are good reasons, who
knows.  Back in the days[tm], finger(1) showed the mail forwards, for

However, I don't really see an issue, because I feel that a big processing
part needs to be done in destination user context anyways.  You might have to
setuid to the user to run a pipe command, and you would want to do this
anyways for file delivery.  As such, it seems that the "root" part of the
process will have to do some delivery anyways.


Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

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