On Tue, Jan 25, 2011 at 11:51:30PM +0200, Teodor MICU wrote:
> 2011/1/25 Harald Jenny :
> > On Tue, Jan 25, 2011 at 04:57:42PM +0200, Teodor MICU wrote:
> >> Good catch. Indeed, $USER is defined on interactive sessions and I was
> >> only thinking about starting at boot.
> >
> > Yes therefor I thin
On Tue, Jan 25, 2011 at 02:16:51PM +0100, Agustin Martin wrote:
> On Mon, Jan 24, 2011 at 09:07:09PM +0100, Harald Jenny wrote:
> > On Mon, Jan 24, 2011 at 08:59:41PM +0200, Teodor MICU wrote:
> > > 2011/1/24 Harald Jenny :
> > > > Ok although the PIDFILE line can be removed with the below code.
>
2011/1/25 Harald Jenny :
> On Tue, Jan 25, 2011 at 04:57:42PM +0200, Teodor MICU wrote:
>> Good catch. Indeed, $USER is defined on interactive sessions and I was
>> only thinking about starting at boot.
>
> Yes therefor I think this change is also necessary do you agree?
Yes.
>> I tend to disagre
On Tue, Jan 25, 2011 at 04:57:42PM +0200, Teodor MICU wrote:
> Hi,
Hello
>
> 2011/1/24 Harald Jenny :
> > On Mon, Jan 24, 2011 at 10:40:06PM +0200, Teodor MICU wrote:
> >> I can only spot some cosmetic issues, otherwise I see no problem. The
> >> change USER -> SYSTEMUSER only makes the diff lar
Hi,
2011/1/24 Harald Jenny :
> On Mon, Jan 24, 2011 at 10:40:06PM +0200, Teodor MICU wrote:
>> I can only spot some cosmetic issues, otherwise I see no problem. The
>> change USER -> SYSTEMUSER only makes the diff larger and not really
>> necessary.
>
> I tend to disagree as USER (as well as USERN
On Mon, Jan 24, 2011 at 09:07:09PM +0100, Harald Jenny wrote:
> On Mon, Jan 24, 2011 at 08:59:41PM +0200, Teodor MICU wrote:
> > 2011/1/24 Harald Jenny :
> > > Ok although the PIDFILE line can be removed with the below code.
> >
> > I'm don't see where PIDFILE is removed.
>
> Just take a look at
On Mon, Jan 24, 2011 at 10:40:06PM +0200, Teodor MICU wrote:
> 2011/1/24 Harald Jenny :
> > On Mon, Jan 24, 2011 at 08:59:41PM +0200, Teodor MICU wrote:
> >> 2011/1/24 Harald Jenny :
> >> > Ok although the PIDFILE line can be removed with the below code.
> >>
> >> I'm don't see where PIDFILE is rem
2011/1/24 Harald Jenny :
> On Mon, Jan 24, 2011 at 08:59:41PM +0200, Teodor MICU wrote:
>> 2011/1/24 Harald Jenny :
>> > Ok although the PIDFILE line can be removed with the below code.
>>
>> I'm don't see where PIDFILE is removed.
>
> Just take a look at the next patch version.
I can only spot so
On Mon, Jan 24, 2011 at 08:59:41PM +0200, Teodor MICU wrote:
> 2011/1/24 Harald Jenny :
> > Ok although the PIDFILE line can be removed with the below code.
>
> I'm don't see where PIDFILE is removed.
Just take a look at the next patch version.
>
> >> Yes. It should be a valid config if /etc/de
2011/1/24 Harald Jenny :
> Ok although the PIDFILE line can be removed with the below code.
I'm don't see where PIDFILE is removed.
>> Yes. It should be a valid config if /etc/default/$NAME that doesn't
>> contain anything. Actually it should be the default to have only
>> comments with the defau
On Mon, Jan 24, 2011 at 07:29:09PM +0200, Teodor MICU wrote:
> Just ignore this. I probably need some coffee.
> Having MILTERSOCKET variable empty is also with the case with the
> proposed configuration where you set your default
> "unix:path/to/socket" value.
Well I will make another upload soon.
On Mon, Jan 24, 2011 at 07:22:17PM +0200, Teodor MICU wrote:
> 2011/1/24 Harald Jenny :
> > On Mon, Jan 24, 2011 at 06:37:37PM +0200, Teodor MICU wrote:
> >> 1) usually you should enclose with "" the full path here:
> >> +PIDFILE=/var/run/amavis/"$NAME".pid
> >> +[ -r /etc/default/"$NAME" ] && . /e
Just ignore this. I probably need some coffee.
Having MILTERSOCKET variable empty is also with the case with the
proposed configuration where you set your default
"unix:path/to/socket" value.
Thanks
2011/1/24 Teodor MICU :
> One more important issue I think we missed so far is to have
> MILTERSOC
2011/1/24 Harald Jenny :
> On Mon, Jan 24, 2011 at 06:37:37PM +0200, Teodor MICU wrote:
>> 1) usually you should enclose with "" the full path here:
>> +PIDFILE=/var/run/amavis/"$NAME".pid
>> +[ -r /etc/default/"$NAME" ] && . /etc/default/"$NAME"
>
> You mean like this?
>
> PIDFILE="/var/run/amavis
On Mon, Jan 24, 2011 at 06:37:37PM +0200, Teodor MICU wrote:
> Hi again,
Hello again :-)
>
> 2011/1/24 Harald Jenny :
> > first thanks to everbody for the valuable input, it helped me a lot to
> > improve
> > this init script. Please take a look at the third version of my patch and
> > comment
Hi again,
2011/1/24 Harald Jenny :
> first thanks to everbody for the valuable input, it helped me a lot to improve
> this init script. Please take a look at the third version of my patch and
> comment on it.
Overall it seems fine, just a few observations:
1) usually you should enclose with "" t
On Mon, Jan 24, 2011 at 05:50:38PM +0200, Teodor MICU wrote:
> 2011/1/24 Harald Jenny :
> > Well as far as I know Debian currently only supports /bin/bash and
> > /bin/dash as
> > providers of /bin/sh so I guess it's currently safe to use echo -n in init
> > scripts.
>
> It's fine. After some dig
Hi all,
first thanks to everbody for the valuable input, it helped me a lot to improve
this init script. Please take a look at the third version of my patch and
comment on it.
Thanks and a nice day
Harald
--- /etc/init.d/amavisd-milter 2010-05-12 23:01:42.0 +0200
+++ /etc/init.d/amavisd-m
2011/1/24 Harald Jenny :
> Well as far as I know Debian currently only supports /bin/bash and /bin/dash
> as
> providers of /bin/sh so I guess it's currently safe to use echo -n in init
> scripts.
It's fine. After some digging I guess I had in mind "echo -e" and
"echo -en" are not working with da
On Mon, Jan 24, 2011 at 05:28:13PM +0200, Teodor MICU wrote:
> Hi,
Hey
>
> 2011/1/24 Julien Cristau :
> >> Yes, it does cover the case where MILTERSOCKET contains something but
> >> not if it is empty. For this I would recommend 'printf' since 'echo
> >> -n' is not portable and not working with
On Mon, Jan 24, 2011 at 05:18:15PM +0200, Teodor MICU wrote:
> Hi,
Hello
>
> 2011/1/24 Agustin Martin :
> > On Mon, Jan 24, 2011 at 02:17:48PM +0100, Harald Jenny wrote:
> >> I will have a to check this - this is meant as a guard against accidently
> >> setting $MILTERSOCKET to "".
>
> Good cat
Hi,
2011/1/24 Julien Cristau :
>> Yes, it does cover the case where MILTERSOCKET contains something but
>> not if it is empty. For this I would recommend 'printf' since 'echo
>> -n' is not portable and not working with /bin/dash.
>>
> Eh, what?
>
> Scripts may assume that `/bin/sh' implements
On Mon, Jan 24, 2011 at 04:20:32PM +0100, Julien Cristau wrote:
> On Mon, Jan 24, 2011 at 17:09:10 +0200, Teodor MICU wrote:
>
> > Hi,
> >
> > 2011/1/24 Harald Jenny :
> > >> 7) You should probably add "-q" for all these executions to avoid
> > >> unwanted strings during start/stop/restart.
> > >
On Mon, Jan 24, 2011 at 17:09:10 +0200, Teodor MICU wrote:
> Hi,
>
> 2011/1/24 Harald Jenny :
> >> 7) You should probably add "-q" for all these executions to avoid
> >> unwanted strings during start/stop/restart.
> >> "`echo $MILTERSOCKET | grep -v ^inet`"
> >
> > If MILTERSOCKET is checked to
On Mon, Jan 24, 2011 at 05:09:10PM +0200, Teodor MICU wrote:
> Hi,
Hello
>
> 2011/1/24 Harald Jenny :
> >> 7) You should probably add "-q" for all these executions to avoid
> >> unwanted strings during start/stop/restart.
> >> "`echo $MILTERSOCKET | grep -v ^inet`"
> >
> > If MILTERSOCKET is c
Hi,
2011/1/24 Agustin Martin :
> On Mon, Jan 24, 2011 at 02:17:48PM +0100, Harald Jenny wrote:
>> I will have a to check this - this is meant as a guard against accidently
>> setting $MILTERSOCKET to "".
Good catch on this. I didn't though of this being empty.
> Damm, seems I wrongly understood
Hi,
2011/1/24 Harald Jenny :
>> 7) You should probably add "-q" for all these executions to avoid
>> unwanted strings during start/stop/restart.
>> "`echo $MILTERSOCKET | grep -v ^inet`"
>
> If MILTERSOCKET is checked to contain text too?
Yes, it does cover the case where MILTERSOCKET contains
On Mon, Jan 24, 2011 at 03:50:04PM +0100, Agustin Martin wrote:
> On Mon, Jan 24, 2011 at 02:17:48PM +0100, Harald Jenny wrote:
> > Hi Augustin
> >
> > On Sun, Jan 23, 2011 at 01:38:47AM +0100, Agustin Martin wrote:
> > > 2011/1/21 Teodor MICU :
> > > > 2011/1/21 Agustin Martin :
> > > >> if [ "$M
On Mon, Jan 24, 2011 at 03:54:49PM +0100, Agustin Martin wrote:
> On Mon, Jan 24, 2011 at 02:08:08PM +0100, Harald Jenny wrote:
> > Hello Agustin Martin
> > >
> > > Also I am not sure of full portability of -a there (although seems to not
> > > be
> > > a problem with dash).
> >
> > No I specif
On Mon, Jan 24, 2011 at 02:08:08PM +0100, Harald Jenny wrote:
> Hello Agustin Martin
> >
> > Also I am not sure of full portability of -a there (although seems to not
> > be
> > a problem with dash).
>
> No I specifically checked the manpage for this.
You are right. Furthermore, just noticed t
On Mon, Jan 24, 2011 at 02:17:48PM +0100, Harald Jenny wrote:
> Hi Augustin
>
> On Sun, Jan 23, 2011 at 01:38:47AM +0100, Agustin Martin wrote:
> > 2011/1/21 Teodor MICU :
> > > 2011/1/21 Agustin Martin :
> > >> if [ "$MILTERSOCKET" ] && [ "`echo $MILTERSOCKET | grep -v ^inet`" ];
> > >> then
> >
Hi Augustin
On Sun, Jan 23, 2011 at 01:38:47AM +0100, Agustin Martin wrote:
> 2011/1/21 Teodor MICU :
> > 2011/1/21 Agustin Martin :
> >> if [ "$MILTERSOCKET" ] && [ "`echo $MILTERSOCKET | grep -v ^inet`" ]; then
> >>
> >> but as Teodor points out (just read it), second check seems to be enough.
>
Hello
On Fri, Jan 21, 2011 at 03:13:05PM +0200, Teodor MICU wrote:
> 2011/1/21 Agustin Martin :
> > if [ "$MILTERSOCKET" ] && [ "`echo $MILTERSOCKET | grep -v ^inet`" ]; then
> >
> > but as Teodor points out (just read it), second check seems to be enough.
>
> Only that I realized latter the inte
Hello Agustin Martin
> Note that ''||' chains are different, will only fail if all components fail.
> However, chaining too much also affects readability.
Ok thanks for this hint.
> It indeed looks better to me, thanks. While I did not test myself I think
> you may have problems with empty $MILT
Hi Teodor Micu
> I had a look at the new patch and I have a few observations.
Thanks
> 1) This construction is fine and simple as recommended in
> /etc/init.d/skeleton:
> # Read configuration variable file if it is present
> [ -r /etc/default/$NAME ] && . /etc/default/$NAME
Ok will look at it.
> Removing is bad bad idea as it leaves amavis user without a working milter.
>
> Alex
Dear Alex
After Squeeze release backports of both libmilter and amavisd-milter will be
made available by me so people will be able to use them.
Kind regards
Harald Jenny
--
To UNSUBSCRIBE, email to debia
Harald Jenny schrieb am Montag, den 24. Januar 2011:
> On Tue, Jan 18, 2011 at 11:57:37AM +0100, Julien Cristau wrote:
> > On Thu, Jan 13, 2011 at 10:04:14 +0100, Harald Jenny wrote:
> >
> > > Dear Gabor Kiss,
> > >
> > > thanks for the information, will test it myself and then release a new
>
On Tue, Jan 18, 2011 at 11:57:37AM +0100, Julien Cristau wrote:
> On Thu, Jan 13, 2011 at 10:04:14 +0100, Harald Jenny wrote:
>
> > Dear Gabor Kiss,
> >
> > thanks for the information, will test it myself and then release a new
> > version.
> > And thanks for your good bug report.
> >
> Can thi
2011/1/21 Teodor MICU :
> 2011/1/21 Agustin Martin :
>> if [ "$MILTERSOCKET" ] && [ "`echo $MILTERSOCKET | grep -v ^inet`" ]; then
>>
>> but as Teodor points out (just read it), second check seems to be enough.
>
> Only that I realized latter the intention of this construction. My
> previous sugges
2011/1/21 Agustin Martin :
> if [ "$MILTERSOCKET" ] && [ "`echo $MILTERSOCKET | grep -v ^inet`" ]; then
>
> but as Teodor points out (just read it), second check seems to be enough.
Only that I realized latter the intention of this construction. My
previous suggestion was to use this construction
On Thu, Jan 20, 2011 at 10:19:28PM +0100, Harald Jenny wrote:
> Hello Agustin Martin
>
> > Typical problems with those chained '&&' appear when 'set -e' is used, but
> > amavisd-milter init script does not use it.
>
> Ah ok thanks will keep this info in mind.
Note that ''||' chains are differen
[Harald please CC: my address otherwise I could not see your responses]
2011/1/20 Harald Jenny :
> I checked with other init scripts an in order to have a consistent coding
> style
> in the init script I replaced the && with if-clauses - could you take a look
> at
> it and tell me if this looks
Hello Agustin Martin
> Typical problems with those chained '&&' appear when 'set -e' is used, but
> amavisd-milter init script does not use it.
Ah ok thanks will keep this info in mind.
> When there are more that two elements in the chain, I usually find these
> if-clauses way more readable an
On Mon, Jan 17, 2011 at 12:28:06AM +0100, Harald Jenny wrote:
> Dear Teodor Micu
>
> thanks for looking at my patch and thanks for your mail, could you please give
> me an example how the && sequences may fail as I've done some tests with it
> and
> it seems it catches all normal configurations,
On Thu, Jan 13, 2011 at 10:04:14 +0100, Harald Jenny wrote:
> Dear Gabor Kiss,
>
> thanks for the information, will test it myself and then release a new
> version.
> And thanks for your good bug report.
>
Can this be fixed ASAP please?
Cheers,
Julien
signature.asc
Description: Digital signa
Dear Teodor Micu
thanks for looking at my patch and thanks for your mail, could you please give
me an example how the && sequences may fail as I've done some tests with it and
it seems it catches all normal configurations, even when a user if specified
for a network milter socket, and the alternat
Hi Harald,
I looked at your patch and I think those multiple "&&" checks in chain
are prone to mistakes in some conditions.
I've reported the same problem with clamav-milter [1] some time ago
and I believe that is a cleaner and better implementation for checking
SOCKET, SOCKET_TYPE and SOCKET_PATH
Dear Gabor Kiss,
thanks for the information, will test it myself and then release a new version.
And thanks for your good bug report.
Kind regards
Harald Jenny
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@list
> privileges. Nonetheless this is an issue so I attached a patch which should
> solve it. Could you please save the attached patch to /tmp/ and apply it by
> issuing
> cd /; patch < /tmp/amavisd-milter_owner-fix.patch
> and afterwards tell me if this solved the problem?
Dear Jenny,
Unfortunately
Dear Gabor Kiss,
first thanks for your bug report, it's definitly a bug in the init script
although the security implications may only be serious when avamisd-new or
amavisd-milter themselves expose a vulnerability as /etc/default/amavisd-milter
is owned/writeable only by root and running the init
Package: amavisd-milter
Version: 1.5.0-2
Severity: grave
Tags: security
Justification: user security hole
After "sudo bash" I issued "/etc/init.d/amavisd-milter restart".
What a surprise! My home directory got owned by user amavis.
Running init script under bash -vx reveals the problem:
[ $MILTE
51 matches
Mail list logo
