FreeRADIUS 3 package will not start

PFbest

It should still stay 31 characters, just avoid the misparsing issues. See man unlang regarding the single quotes. The single quotes shouldn't count as part of the secret.

Ummmmmm
It returns error as in image

nas.png_thumb

doktornotor

Eh, well… edit this line to 33. I just wanted you to test whether it stops breaking the config, that's all.

PFbest

@doktornotor:

Eh, well… edit this line to 33. I just wanted you to test whether it stops breaking the config, that's all.

Cool, tested.
Results are:

doktornotor

Yes, as said, the secret does not really change. I'll do a PR to add single quotes around the secret automatically so that you can input it without quotes in both the AP and pfSense.

https://redmine.pfsense.org/issues/7836
https://github.com/pfsense/FreeBSD-ports/pull/415

PiBa

Thanks doktornotor 8)
One question though, can a single quote (or backslash) be part of the secret? And if so, should it also be escaped.?.
Found this http://networkradius.com/doc/3.0.10/raddb/syntax/data_string.html but not sure its about the exact same software.

Example
'a string with spaces'
'a string with \'quotes\' in it'
'a string with a backslash \\ in it'

Um ok, reading your pullrequest while writing this i realize your asking the enduser to do this, but then the check for 31 characters should perhaps also allow more characters.?. Wouldnt it be easier to let the code writing the config file do the proper escaping?

doktornotor

There are tons of places in pfSense where the code won't work as expected when doing things like putting various UTF-8 accented chars, or even multibyte characters into passwords, secrets and other settings since it either breaks config.xml or strlen() and other non mb_ prefixed functions don't handle this.

https://redmine.pfsense.org/issues/7186
https://redmine.pfsense.org/issues/7423
https://redmine.pfsense.org/issues/7623

The field in freeradiusclients.xml is not base64-encoded because it wasn't possible with XML and pasword-type field. Now, when you attempt to use some functions to automatically escape/replace things with those non-encoded strings, you run into things like this one. When you switch the field to use base64, you need to write code to upgrade the config automatically on installing the next package version.

Afraid someone else will need to do the job since I frankly think that people that insist on shooting themselves in the foot need to pick up the pieces. (I recall a couple of threads here where people were complaining that putting a carriage return character in password makes their life miserable with password prompts… ::))

doktornotor

And one final thing - the idea to "let the code writing the config file do the proper escaping" is very cool until you run into a genius who invents a secret like f#$k'1t and you don't know whether he meant to escape the ' or literally use ' :-X

PiBa

Ok the ' and \ aren't 'very special' like some of the other examples you provide, but i get the point ;D
Having a carriage return in a password must be very secure i havn't thought about using that in any my passwords sofar ;).

imho in general escaping in config files should be done by 'the software', and if a genius did it manually, then i suppose thats to bad for them when pfSense gets 'fixed'. Cant expect the enduser to know/lookup every escape sequence for each piece of software used by pfSense. So your patch certainly helps make that clear for this field. But i guess my point is made :)

Lets wait for someone to run into it and then perhaps take another look.

PFbest

@doktornotor:

Yes, as said, the secret does not really change. I'll do a PR to add single quotes around the secret automatically so that you can input it without quotes in both the AP and pfSense.

https://redmine.pfsense.org/issues/7836
https://github.com/pfsense/FreeBSD-ports/pull/415

Cool! ;)

Thanks! ;D

doktornotor

@PiBa:

i realize your asking the enduser to do this, but then the check for 31 characters should perhaps also allow more characters.?

Actually I'd say it works properly as is:


$post['varclientsharedsecret'] = '0123456789\\\\0123456789\\0123456789\\\\\'\'\'';
echo $post['varclientsharedsecret'];
echo "\n";
echo strlen($post['varclientsharedsecret']);

Result:


0123456789\\0123456789\0123456789\\'''
38

Now, consider trying to match/escape things (meant as literal unescaped string) such as \' properly:

preg_match_all("/[\\\\](?!\\'){1}/", $post['varclientsharedsecret'])

just to match a single \ while avoiding hitting the "escaped" ' if it follows. Oooops shit… Well I'd say the escaping it way better left to users.