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

 
 

bug #33412: too little space in additional header options

Submitted by:  None
Submitted on:  Thu 26 May 2011 08:53:59 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Werner Baumann <wbaumann>
Open/Closed: Closed

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
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.

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
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

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
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

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
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

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 22 Apr 2014 07:39:59 PM UTCwbaumannOpen/ClosedOpen=>Closed
    Fri 18 Apr 2014 08:11:01 PM UTCwbaumannStatusPostponed=>Fixed
    Thu 19 Jul 2012 04:29:15 PM UTCwbaumannStatusFixed=>Postponed
    Sat 25 Jun 2011 04:31:02 PM UTCwbaumannStatusConfirmed=>Fixed
    Thu 26 May 2011 08:55:26 PM UTCwbaumannSeverity1 - Wish=>3 - Normal
    Thu 26 May 2011 08:55:09 PM UTCwbaumannStatusNone=>Confirmed
      Assigned toNone=>wbaumann
    Thu 26 May 2011 08:53:59 PM UTCwbaumannReassign itemdavfs2, sr #107699=>davfs2, bug #33412

    Back to the top


    Powered by Savane 3.1-cleanup