View Issue Details

IDProjectCategoryView StatusLast Update
0004891unrealircdpublic2020-09-27 18:26
ReporterGottem Assigned Tosyzop  
Status closedResolutionfixed 
Platformx86_64OSDebianOS Version7 (wheezy)
Product Version4.0.10 
Fixed in Version5.0.0 
Summary0004891: staff-file doesn't work with URLs
Description<PeGaSuS> uh.. about m_staff.. seems remotes don't work with that?

He wants to use something like:
    set { staff-file "https://user:[email protected]/conf/staff.conf"; };

Which according to the source of m_staff is perfectly possible (cURL also supports htpasswd auth afaik):
    if (url_is_valid(ce->ce_vardata)) { download_staff_file(ce) }

Except it returns this error:
    *** error: Unable to open file '(null)': Bad address

So I went ahead and tested some things. Using any form of the URL will result in the same error, so any of these:
    * http(s)://user:[email protected]/conf/staff.conf
    * http(s)://user:[email protected]/staff.conf
    * http(s)://host.tld/conf/staff.conf
    * http(s)://host.tld/staff.conf

The webserver also responds with a nice HTTP 200 code every time, so no problems there. I found that the following call in download_staff_file() returns either NULL or garbage data:
    file = url_getfilename(ce->ce_vardata);

Which means that the line right below will also be NULL/garbage:
    filename = unreal_getfilename(file);

But judging by the url_getfilename() code it doesn't do anything special, just figure out where the :// is then increment pointers until it finds the next slash (so you _should_ end up with "conf/staff.conf") and return what's left. I made sure ce->ce_vardata is sane, which it is.

The exact function that throws the error is unreal_copyfile(), which it does because the const char *src it gets is NULL.
Steps To ReproduceUse something like the following in your config:
set { staff-file "https://host.tld/conf/staff.conf"; };

Rehash and watch the server console.
Additional InformationAlso reproducible on 4.0.11 (latest from git), which is used by PeGaSuS. My test/dev net is on 4.0.10.

Severity set to major as this seems to be a bug in src/url.c, which may or may not affect other modules.
TagsNo tags attached.
3rd party modules



2020-09-27 18:26

administrator   ~0021766

Works fine for me, so probably accidentally fixed? ;)
Don't know since what version, I'm tagging as 5.0.0.

If not fixed for you or others, let us know.

Issue History

Date Modified Username Field Change
2017-03-09 18:02 Gottem New Issue
2017-03-11 09:58 syzop Severity major => minor
2020-09-27 18:26 syzop Assigned To => syzop
2020-09-27 18:26 syzop Status new => closed
2020-09-27 18:26 syzop Resolution open => fixed
2020-09-27 18:26 syzop Fixed in Version => 5.0.0
2020-09-27 18:26 syzop Note Added: 0021766