bugdavfs2 - Bugs: bug #33412, too little space in additional...

 
 

bug #33412: too little space in additional header options

Submitter:  None
Submitted:  Thu 26 May 2011 08:53:59 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 18 Apr 2014 08:11:01 PM UTC, comment #7: 

The problem should now be fixed with improved cookie support.
The fix is in the CVS sources branches MAIN and branch rel-1-4-6.

Werner

- <_71007>
Thu 19 Jul 2012 04:29:15 PM UTC, comment #6: 

Release 1.4.7 fixes the problem with restricted lenght of custom headers.

But cookie support stil needs a redesign.

- <_71007>
Mon 27 Jun 2011 06:49:50 AM UTC, comment #5: 

Hi.

Thanks again.

On my way to this solution I tried the server_cert and client_cert parts from the config file. It did not work presumably because of the cookie support.

I don't know if full cookie support will do the trick, but it would definitely be worth a try.

As far as time goes, the current solution works for me, so there is no haste. :-)

Thanks again
  Andre

Andre Naujoks <nautsch>
Sat 25 Jun 2011 04:31:02 PM UTC, comment #4: 

The bug is fixed in the CVS-sources. Instead of using a bigger buffer I parse the line in place (parsing will only reduce the size and never increase it).

One more question about the single sign on:

As far as I can see the URL for authentication is the same as the URL to mount in your case. If this is true full support for cookies would solve the problem. davfs2 already supports SSL/TLS and client certificates. See options

  • sever_cert: it is a misnomer and intendet for cacert
  • client_cert: it must be in PKCS#12 format containing the certificate and the private key. If the key is password protected, the password can be stored in secrets.


I intend to give it a try and extend the support for cookies. But this will take some time as there are some other issues I have to care about first.

Cheers
Werner

- <_71007>
Fri 27 May 2011 11:53:35 AM UTC, comment #3: 

Hi.

Thanks for the quick reply and being open to this :-)

The problem with these things is, that they are far from being standards conform.

In this case we had to make a http request with curl like this:

curl -s -L --cookie-jar $cookiejar -o /dev/null -k --sslv3 --key $CERTOWNER-key.pem --cert $CERTOWNER-cert.pem --cacert $CACERT $MOUNTURL

Of yourse with all the variables set accordingly or to temporaray files.

The next step is to parse the cookiejar file, which is output by curl and put them into a davfs2.conf file with an additional "ask_auth 0", because there is no further authentication.

The cookies needed were ORA_WX_SESSION, OHS-collaboration. JSESSIONID, ORA_CONTENT_DAV. And i think the order was important, too.

To integrate this kind of stuff, davfs2 would need to support the whole certificate stuff, that curl does. And I honestly don't know anything about that. I was happy when the setup worked.

It would help though, if davfs2 would support cookies in full. That would at least get rid of the JSession Cookie and probably more.

Regards
  Andre Naujoks

Andre Naujoks <nautsch>
Thu 26 May 2011 08:53:59 PM UTC, comment #2: 

This item has been reassigned from the project davfs2 support tracker to your tracker.

The original report is still available at support #107699

Following are the information included in the original report:

[field #0]                  Item ID: 107699
[field #1]                 Group ID: 10199
[field #2]              Open/Closed: Open
[field #3]                 Severity: 1 - Wish
[field #4]                  Privacy: Public
[field #7]                         : Unknown support Field Display Type
[field #8]                         : Unknown support Field Display Type
[field #9]                 Category: None
[field #10]             Submitted by: None
[field #11]              Assigned to: wbaumann
[field #12]             Submitted on: Thu 26 May 2011 01:48:32 PM GMT
[field #13]                  Summary: too little space in additional header options
[field #14]      Original Submission: Hi.

We are using davfs2 to mount a share on an oracle server. The server needs a so called Single Sign On before the actual mount can be done.

The single sing on is done with a curl call to the server with some certificate and the result of this are some cookies, which need to be transmitted every time a request is made to the server.

The cookies are written into a davfs2.conf file as "add_header Cookie ..." lines, which is in turn then used by a call to mount.davfs2.

The problem here is, that davfs2 only accepts 253(?) bytes per line in a config file and the cookies are much longer. I patched it for me locally to accept more, but I'd like to know, if it would be possible to get longer lines in the upstream version, too. We now use 2048 byte in mount.davfs2.c ... but see this patch against 1.4.6 (from debian sid)

--- mount_davfs.c 2011-05-26 15:35:31.673037814 +0200
+++ mount_davfs.c_p 2011-05-26 15:35:18.740079775 +0200
@@ -1994,9 +1994,9 @@
 
     int state = SPACE;
     int parm_no = 0;
-    char buf[254];
+    char buf[2048];
     char *pos = buf;
-    char *end = buf + 253;
+    char *end = buf + 2047;
     char *p = line;
 
     while ((state != END) && (state != ERROR)) {

I would be very thankful, if this would get upstream, as I don't think it will harm anyone and it would rid me of taking care of patching newer versions as they come out.

Thanks and Regards
  Andre Naujoks

[field #16]               Item Group: None
[field #17]                   Status: Confirmed
[field #18]        Component Version: None
[field #19]         Operating System: GNU/Linux
[field #20]          Reproducibility: None
[field #21]               Size (loc): None
[field #22]            Fixed Release: None
[field #23]          Planned Release: None
[field #24]                   Effort: 0.00
[field #28]                 Priority: 5 - Normal
[field #31]         Percent Complete: 0%
[field #33]                  Release: None
[field #36]         Originator Email: nautsch2@googlemail.com
[field #58]     Custom Select Box #1: None
[field #59]     Custom Select Box #2: None
[field #60]     Custom Select Box #3: None
[field #61]     Custom Select Box #4: None
[field #62]     Custom Select Box #5: None
[field #63]     Custom Select Box #6: None
[field #64]     Custom Select Box #7: None
[field #65]     Custom Select Box #8: None
[field #66]     Custom Select Box #9: None
[field #67]    Custom Select Box #10: None

- <_71007>
Thu 26 May 2011 08:51:22 PM UTC, comment #1: 

Thanks for the report and the patch.

Looks like I have created another example in the category
"How fixed size buffers that are meant to be much bigger than necessary turn out to be far to small."

I think I should drop that fixed size buffer alltogether and allocate the required space dynamically. Performance is of not of much concern at this point as the file is only parsed once.

I will move this report to the bug tracker so I will not forget about ist.

Occasionally other users have problems with Single Sign On and other cookie based authentication and more detailed information about how you solved the problem might be useful for them. As there is no better place at the moment, a report on this support tracker might be a good idea. But I should include it into the documentation some day.

Have you any idea how this could be integrated into davfs2?

Cheers
Werner

- <_71007>
Thu 26 May 2011 08:53:59 PM UTC, original submission:  

Hi.

We are using davfs2 to mount a share on an oracle server. The server needs a so called Single Sign On before the actual mount can be done.

The single sing on is done with a curl call to the server with some certificate and the result of this are some cookies, which need to be transmitted every time a request is made to the server.

The cookies are written into a davfs2.conf file as "add_header Cookie ..." lines, which is in turn then used by a call to mount.davfs2.

The problem here is, that davfs2 only accepts 253(?) bytes per line in a config file and the cookies are much longer. I patched it for me locally to accept more, but I'd like to know, if it would be possible to get longer lines in the upstream version, too. We now use 2048 byte in mount.davfs2.c ... but see this patch against 1.4.6 (from debian sid)

--- mount_davfs.c 2011-05-26 15:35:31.673037814 +0200
+++ mount_davfs.c_p 2011-05-26 15:35:18.740079775 +0200
@@ -1994,9 +1994,9 @@
 
     int state = SPACE;
     int parm_no = 0;
-    char buf[254];
+    char buf[2048];
     char *pos = buf;
-    char *end = buf + 253;
+    char *end = buf + 2047;
     char *p = line;
 
     while ((state != END) && (state != ERROR)) {

I would be very thankful, if this would get upstream, as I don't think it will harm anyone and it would rid me of taking care of patching newer versions as they come out.

Thanks and Regards
  Andre Naujoks

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nautsch (Posted a comment)
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-22 _71007 Open/ClosedOpen Closed
    2014-04-18 _71007 StatusPostponed Fixed
    2012-07-19 _71007 StatusFixed Postponed
    2011-06-25 _71007 StatusConfirmed Fixed
    2011-05-26 _71007 Severity1 - Wish 3 - Normal
    2011-05-26 _71007 StatusNone Confirmed
        Assigned toNone _71007
    2011-05-26 _71007 Reassign itemdavfs2, sr #107699 davfs2, bug #33412

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code