Mailing List Archive

HTTP Authorization Patch
Hello, we recently ran into an issue with varnish when http authorizations
were concerned so I created this patch [ it can probably be done a whole lot
better ]. The attached patch has a function cnt_auth which calls an
external function that you must insert yourself. It passes the external
function the username and password base64 encoded, the users ip, and the
path of the filename. It is up to your external function to decide whether
the credentials presented are correct or not and return a 1 or -1. (true or
false). If false it sets the sp->handling to VCL_RET_PASS which will pass
it off to the server. The patch also modifies cnt_fetch function to check
for a 401 status code to prevent us from caching an actual 401 Unauthorized
status and serving that to a legitimate client.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.linpro.no/pipermail/varnish-misc/attachments/20070221/e81a60ee/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: varnish-auth-0.1.patch
Type: text/x-patch
Size: 1480 bytes
Desc: not available
Url : http://projects.linpro.no/pipermail/varnish-misc/attachments/20070221/e81a60ee/attachment.bin
HTTP Authorization Patch [ In reply to ]
In message <dacbdcd10702210839n1d8b3be5gdb73de697a492c0c at mail.gmail.com>, cripy
writes:

>Hello, we recently ran into an issue with varnish when http authorizations
>were concerned so I created this patch [ it can probably be done a whole lot
>better ]. The attached patch has a function cnt_auth which calls an
>external function that you must insert yourself.

One of the most damanging accusations ever launched against any
programming language was in one of the historical attacks on PASCAL.

I can't remember who exactly wrote it, but the operative sentence was:

"Worst of all, there is no escape."

VCL has a planned escape mechanism, but I have not said anything
about it yet, wanting to see if anybody actually needed it.

The concept is that hat arbitrary C-code can be inserted into VCL
programs, possibly something like:

sub vcl_recv {
C{
{
char *p = VRT_GetHdr(sp, 1, "\005Host:");

...
}
}C
}

That should allow you to do what your patch does, entirely
from within VCL.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
HTTP Authorization Patch [ In reply to ]
On 2/22/07, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> In message <dacbdcd10702210839n1d8b3be5gdb73de697a492c0c at mail.gmail.com>,
> cripy
> writes:
>
> >Hello, we recently ran into an issue with varnish when http
> authorizations
> >were concerned so I created this patch [ it can probably be done a whole
> lot
> >better ]. The attached patch has a function cnt_auth which calls an
> >external function that you must insert yourself.
>
> One of the most damanging accusations ever launched against any
> programming language was in one of the historical attacks on PASCAL.
>
> I can't remember who exactly wrote it, but the operative sentence was:
>
> "Worst of all, there is no escape."
>
> VCL has a planned escape mechanism, but I have not said anything
> about it yet, wanting to see if anybody actually needed it.
>
> The concept is that hat arbitrary C-code can be inserted into VCL
> programs, possibly something like:
>
> sub vcl_recv {
> C{
> {
> char *p = VRT_GetHdr(sp, 1, "\005Host:");
>
> ...
> }
> }C
> }
>
> That should allow you to do what your patch does, entirely
> from within VCL.
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by
> incompetence.
>


Hey Poul,
Thanks for the prompt response and help. However, I can't seem to get
this to work properly I am receiving the following error upon varnishd
startup:

Expected action, 'if' or '}'
In VCL code Line 7 Pos 16
C{
----------------#-

Any help is appreciated as I believe that VCL is the best approach for
implementing this until something similar is implemented in varnish. Thanks
again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.linpro.no/pipermail/varnish-misc/attachments/20070222/29b9679e/attachment.htm
HTTP Authorization Patch [ In reply to ]
On Feb 22, 2007, at 12:14 AM, Poul-Henning Kamp wrote:

> The concept is that hat arbitrary C-code can be inserted into VCL
> programs, possibly something like:

I can't decide if I want to say "neat" or "avoid avoid avoid!".

I understand that you don't want to embed a better memory managed
(etc) language, but if you go the "C in the config file" route at the
very least we'll need some tools to test the configuration file (say
throw random data at it to test for basic buffer overflows etc).


- ask

--
http://develooper.com/ - http://askask.com/
HTTP Authorization Patch [ In reply to ]
In message <dacbdcd10702221554k37e77a08rbc147a7db6e0f29b at mail.gmail.com>, cripy
writes:

>Hey Poul,
> Thanks for the prompt response and help. However, I can't seem to get
>this to work properly I am receiving the following error upon varnishd
>startup:

Easy does it, I said it was a plan I had, not that I had done it yet.


--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
HTTP Authorization Patch [ In reply to ]
In message <02769D74-A35A-4BD5-82D4-5280E2D1EAD9 at develooper.com>, =?ISO-8859-1?
Q?Ask_Bj=F8rn_Hansen?= writes:
>
>On Feb 22, 2007, at 12:14 AM, Poul-Henning Kamp wrote:
>
>> The concept is that hat arbitrary C-code can be inserted into VCL
>> programs, possibly something like:
>
>I can't decide if I want to say "neat" or "avoid avoid avoid!".

Right, that's why I didn't even mention it, until somebody else
brought forth a need for it.

The article I refered to is worth a read as background reading
at this point:

http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz


>I understand that you don't want to embed a better memory managed
>(etc) language, but if you go the "C in the config file" route at the
>very least we'll need some tools to test the configuration file (say
>throw random data at it to test for basic buffer overflows etc).

From a philosophical point of view, if you use the C{ }C escape mechanism,
you get what you ask for, so don't expect me to spend a lot of time
trying to protect you from yourself, that would defeat the purpose.

From a more practical point of view, writing a stress-tester for
unspecified C-code is not tricky, it is virtually impossible.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.