I've put a release candidate on the net as: ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.4rc2.tar.gz After a few months of hard work, this should be the final release candidate. Please test it. We don't want any last-minute "oops" marring the release. The list of changed items is long. A number of small bug fixes, and a number of useful new features. We've also added more tests, to be sure that future releases don't go "backwards" in functionality and stability. Alan DeKok.
On 26 Aug 2014, at 12:29, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 25/08/14 13:37, Alan DeKok wrote:
I've put a release candidate on the net as:
Has the tag been pushed to github?
I've added one. It's not quite the same as the tar Alan rolled, but it's pretty close. https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_4_rc2.ta... It seems in the tar'd version there's an extra function 'realm_home_server_sanitize' which has a lot of the validation logic broken out of 'realm_home_server_add'. I've added that to the main repo, as it's a useful change, but it's not included in the rc2 on github because that would involve rewriting history. Functionally the code is identical. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 25/08/14 13:37, Alan DeKok wrote:
I've put a release candidate on the net as:
ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.4rc2.tar.gz
57bdaa3 (the hash for the tag Arran put in) seems to be pretty stable; run under load for a couple of hours, no obvious problems.
On 26 Aug 2014, at 15:36, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 25/08/14 13:37, Alan DeKok wrote:
I've put a release candidate on the net as:
ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.4rc2.tar.gz
57bdaa3 (the hash for the tag Arran put in) seems to be pretty stable; run under load for a couple of hours, no obvious problems.
Great, thanks for testing. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.4rc2.tar.gz
After a few months of hard work, this should be the final release candidate. Please test it.
We don't want any last-minute "oops" marring the release.
The list of changed items is long. A number of small bug fixes, and a number of useful new features. We've also added more tests, to be sure that future releases don't go "backwards" in functionality and stability.
Hm, this doesn't work so well when it comes to my invocation of rlm_linelog: (24) linelog : EXPAND %{%{Acct-Status-Type}:-%{%{reply:Packet-Type}:-format}} (24) linelog : --> Access-Reject (24) linelog : EXPAND /var/log/radius/activity.log (24) linelog : --> /var/log/radius/activity.log (24) ERROR: linelog : rlm_linelog: Failed to create directory /var/log/radius: Operation not permitted (24) [linelog] = fail This was running as root with -X. /var/log/radius exists (since months) and does not need to be created. Trying to do so is bound to fail. Reverting to my current production version (which is a 3.0.2 with custom patches) does not have the same behaviour, it logs to /var/log/radius/activity.log as it should. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi again, looking a the code inside rad_mkdir, it realises that the directory exists, but then tries a chmod() with hard-wired permissions to 0700 (rlm_linelog.c harwired this value) (why?) which fails (why, I don't know, I'm root after all). That chmod() wasn't done in earlier versions; used stat() and returned 0 without making a fuss. Greetings, Stefan Winter On 28.08.2014 08:35, Stefan Winter wrote:
Hi,
ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.4rc2.tar.gz
After a few months of hard work, this should be the final release candidate. Please test it.
We don't want any last-minute "oops" marring the release.
The list of changed items is long. A number of small bug fixes, and a number of useful new features. We've also added more tests, to be sure that future releases don't go "backwards" in functionality and stability.
Hm, this doesn't work so well when it comes to my invocation of rlm_linelog:
(24) linelog : EXPAND %{%{Acct-Status-Type}:-%{%{reply:Packet-Type}:-format}} (24) linelog : --> Access-Reject (24) linelog : EXPAND /var/log/radius/activity.log (24) linelog : --> /var/log/radius/activity.log (24) ERROR: linelog : rlm_linelog: Failed to create directory /var/log/radius: Operation not permitted (24) [linelog] = fail
This was running as root with -X.
/var/log/radius exists (since months) and does not need to be created. Trying to do so is bound to fail.
Reverting to my current production version (which is a 3.0.2 with custom patches) does not have the same behaviour, it logs to /var/log/radius/activity.log as it should.
Greetings,
Stefan Winter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Stefan Winter wrote:
Hi again,
looking a the code inside rad_mkdir, it realises that the directory exists, but then tries a chmod() with hard-wired permissions to 0700 (rlm_linelog.c harwired this value) (why?) which fails (why, I don't know, I'm root after all).
SELinux?
That chmod() wasn't done in earlier versions; used stat() and returned 0 without making a fuss.
It's an attempt at security. If the call to rad_mkdir() says that the directory should be 0755, then the directory should be set to that. I've pushed a fix. Alan DeKok.
Hi,
looking a the code inside rad_mkdir, it realises that the directory exists, but then tries a chmod() with hard-wired permissions to 0700 (rlm_linelog.c harwired this value) (why?) which fails (why, I don't know, I'm root after all).
SELinux?
No, turned out that the directory is owned by root, but the attempt at chmod() was after radiusd dropped its UID/GID to the non-privileged radiusd/radiusd. In effect, radiusd at runtime forces the log dir to have same owner that is also the uid/gid of the daemon (else calling chmod() is not authorized); and it scrubs any changes to in permissions which an admin may do on the filesystem himself. Even if the same-ownership is the default on many installations, and 755 is probably defaulty as well, enforcing that silently in code is a significant behaviour change (and none I see in the Changelog even). Not what I expected in a patchlevel update anyway.
That chmod() wasn't done in earlier versions; used stat() and returned 0 without making a fuss.
It's an attempt at security. If the call to rad_mkdir() says that the directory should be 0755, then the directory should be set to that.
I've pushed a fix.
Hm. If the admin thinks otherwise, shouldn't his will be respected? Also, the fix looks misplaced? I think it's the chmod() here: if (rcode < 0) { if (errno == EEXIST) { return chmod(directory, mode); } The directory exists, so this is the code path with the "strange" chmod(). Your change doesn't do the chmod() on actual newly created directories. I believe that *there* it makes sense to keep the chmod() because you'll be populating something that didn't exist before with a sane default. At the other place, you're changing things an admin did without asking him. Greetings, Stefan Winter
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Stefan Winter wrote:
No, turned out that the directory is owned by root, but the attempt at chmod() was after radiusd dropped its UID/GID to the non-privileged radiusd/radiusd.
I thought that might be the case.
Also, the fix looks misplaced? I think it's the chmod() here:
I've pushed a fix. Alan DeKok.
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers -
Stefan Winter -
Zenon Mousmoulas