Sorry Dan, but you'r wrong again:
#> ps|grep postfix
root 874 0.0 0.3 2756 816 ?Ss May11 0:00
/usr/lib/postfix/master
postfix878 0.0 0.6 5900 1600 ?SMay11 0:00 qmgr -l
-t fifo -u -c
postfix 20510 0.0 0.7 5880 2040 ?S21:41 0:00 pickup
On Thu, May 13, 2004 at 01:19:14PM +0200, Ilja Booij wrote:
> Dan Weber wrote:
> >>I've just checked on a webserver:
> >>the 'root' apache process also is in state LISTEN and runs as root. So I
> >>guess that's the way its' supposed to be. I presume Apache would be
> >>doing The Right Thing.
Its
It's just the other way around.
There are too many assumptions on '\n' line endings in the code.
Inserting '\r\n' breaks things..
The problem is that quite a lot of the assumptions in code that is, for
me, until now, quite unreadable.
Ilja
Aaron Stone wrote:
So we need to add the \r's a
So we need to add the \r's at the time of message insertion?
I'm not surprised, and I've been thinking that we'd have to do that, because
it seems clear that there are deep assumptions of \r\n line endings
throughout. It's not ideal, since we really should be keeping things in the
same format as t
Ilja Booij wrote:
BTW, I haven't been able to use OutLook yet to test the message
problems, as our only Windows machine here is in use at the moment.
I've taken a look at the OutLook problem using OutLook Express. The
cause of the problem was the fact that a message inserted via lmtp has
\r\
Hi all,
in an attempt to fix message insertion errors, I did the following:
I seperated the code which gets the message from the MTA from the code
that seperates the header from the body, and the code that inserts the
message into the database.
The pipe version (dbmail-smtp) uses fread() to
Ilja was quit correct:
apache-1.3 on debian:
root 21353 0.0 0.1 144880 1548 ? SMay09 0:08 /usr/sbin/apache
www-data 24087 0.0 0.4 147500 4220 ? S13:40 0:00 /usr/sbin/apache
www-data 24606 0.0 0.4 147500 4220 ? S13:42 0:00 /usr/sbin/apache
www-data 25
On Thu, 13 May 2004 13:19:14 +0200
Ilja Booij <[EMAIL PROTECTED]> wrote:
> Dan Weber wrote:
> > On Thu, May 13, 2004 at 10:29:44AM +0200, Ilja Booij wrote:
> >
> >>I've just checked on a webserver:
> >>the 'root' apache process also is in state LISTEN and runs as root. So I
> >>guess that's the
Dan Weber wrote:
On Thu, May 13, 2004 at 10:29:44AM +0200, Ilja Booij wrote:
I've just checked on a webserver:
the 'root' apache process also is in state LISTEN and runs as root. So I
guess that's the way its' supposed to be. I presume Apache would be
doing The Right Thing.
I've done some t
On Thu, May 13, 2004 at 12:45:59AM -, Aaron Stone wrote:
> To be honest, I haven't read your patch nor have I read the particular parts
> of DBMail in question in any detail... so it's entirely possible that you're
> seeing an unhandled corner case or a different angle that I'm not aware of at
On Thu, May 13, 2004 at 10:29:44AM +0200, Ilja Booij wrote:
>
> I've just checked on a webserver:
> the 'root' apache process also is in state LISTEN and runs as root. So I
> guess that's the way its' supposed to be. I presume Apache would be
> doing The Right Thing.
> >
> >I've done some testin
Hi,
Paul J Stevens wrote:
Well, Dan's idea to move the drop_privileges call to server.c does
deserve some attention. Currently privileges are dropped in the child
process that itselfs forks off the client handlers. There remains a
single process running as root. Could this pose a threat? Afaik
Well, Dan's idea to move the drop_privileges call to server.c does deserve some
attention. Currently privileges are dropped in the child process that itselfs
forks off the client handlers. There remains a single process running as root.
Could this pose a threat? Afaik, this process is indeed in
Go to this page, and scroll all the way to the bottom. Enter your email
address in the unsubscribe box, and you will receive an email for confirmation
and directions on any further actions that you might need to take...
http://mailman.fastxs.net/mailman/listinfo/dbmail-dev
Jason Cornish <[EMAIL
Dan Weber <[EMAIL PROTECTED]> said:
>
> On Thu, May 13, 2004 at 12:16:04AM -, Aaron Stone wrote:
> > Yes, but let's do it right and cleanly!
> >
> > So if you look in misc.c, there's a function called drop_privileges which
> > sets the uid/gid to that of the unprivileged user specified in the
On Thu, May 13, 2004 at 12:16:04AM -, Aaron Stone wrote:
> Yes, but let's do it right and cleanly!
>
> So if you look in misc.c, there's a function called drop_privileges which sets
> the uid/gid to that of the unprivileged user specified in the dbmail.conf
> file. It is called from lmtpd.c, a
Yes, but let's do it right and cleanly!
So if you look in misc.c, there's a function called drop_privileges which sets
the uid/gid to that of the unprivileged user specified in the dbmail.conf
file. It is called from lmtpd.c, as with all of the other daemons... is it not
doing the trick for you?
On Wed, May 12, 2004 at 11:06:51PM -, Aaron Stone wrote:
> So the functions to choose from are:
>
> setuid/setgid: Available on all platforms. Sets effective uid/gid. On Linux,
> sets real and saved uid/gid if caller is root. On BSD, always sets all of
> them.
>
> seteuid/setegid: Defined by
So the functions to choose from are:
setuid/setgid: Available on all platforms. Sets effective uid/gid. On Linux,
sets real and saved uid/gid if caller is root. On BSD, always sets all of them.
seteuid/setegid: Defined by BSD, available on Linux. Sets effective uid/gid.
setreuid/setregid: Also B
On Wed, May 12, 2004 at 05:38:59PM -0400, Dan Weber wrote:
> The alternatives are seteuid and setegid which can be there with
> an ifndef _GNU_SOURCE
Here this looks good. this is another patch to deal with these
_GNU_SOURCE issues. I fixed acconfig.h by adding
#undef _GNU_SOURCE then I put t
21 matches
Mail list logo
