Mark Haney wrote:
I don't think I've ever flamed anyone in my life, but now I believe I have to.
Good luck.
Sadly, it seems like this is a recurring theme with you. I've seen literally DOZENS of posts from you in the archives and through google and in every single one of them there IS NOT a shred of helpful advice except to RTFM.
Only if you cherry-pick the posts where people ignore the documentation, and I tell them to read it. If you look at the bulk of my posts, it has content, and helps people with real problems. You've just shown your agenda. You don't want to look at facts, you just want to prove I'm bad, and you're better than me.
The vaunted documentation is just about the worst I've ever seen.
Then you haven't been out much. The documentation isn't perfect, but every single configuration item is exhaustively documented. The sad thing is that it doesn't hold your hand. It requires you to put the pieces together yourself, and to do some thinking.
- From radiusd.conf:
# On systems with shadow passwords, you might have to set 'group = shadow' # for the server to be able to read the shadow password file. If you can # authenticate users while in debug mode, but not in daemon mode, it may be # that the debugging mode server is running as a user that can read the # shadow info, and the user listed below can not.
(FWIW, this documentation is beyond incomprehensible. The 'group = shadow' is not about using the group 'shadow' to access /etc/shadow it's changing the group on /etc/shadow to 'radiusd'.)
No, you're wrong. The documentation says what it means, and means what it says. I'll explain like you're 5. /etc/shadow is owned by user root, and group shadow. It has "rw" permissions for the user, and "r" permissions for the group. The "other" fields have no permissions, so no one else has permissions to read it. The "group" configuration entry for FreeRADIUS has the documented meaning, which you ignored: # user/group: The name (or #number) of the user/group to run radiusd as. i.e. You can configure FreeRADIUS to run as un-privileged user "radiusd", and group "shadow". So... putting 2 and 2 together, we get 4. Setting "group = shadow" means "run FreeRADIUS as group shadow". Since /etc/shadow can be read by anyone in group "shadow", this means that FreeRADIUS will now be able to read /etc/shadow. See? It's simple. Your interpretation of the documentation is bizarre. Setting "group = shadow" for FreeRADIUS means changing the group of /etc/shadow to "radiusd"? Well, no. The documentation doesn't say that.
Radiusd.conf DOES NOT talk about issues with reading /etc/shadow. ANYWHERE. PERIOD.
It presumes you can put 2 and 2 together. Sadly, you've done that and gotten "purple" instead of "4".
In the one post (which I cannot dig up now since I've pulled up so many the last two hours), it's RECOMMENDED not changing read permissions on /etc/shadow. Even though the OP actually got it working that way. And IIRC, it was a reply from you and someone else in the thread that made that recommendation.
It's not recommended because it's not necessary. If you know nothing about Unix security, you can "chmod 777" all of the files, and get any process to read any file. It will "work", but it won't be secure. Which is why we don't recommend it.
I have to be honest. I've been doing this a LONG time. 20 years or so. And I've NEVER dealt with a more unprofessional and unhelpful mailing list as I have with this list. What should be a relatively 'simple' solution is anything but with this list. I'm no noob working with linux/unix and text configuration files, and yet I feel FARTHER away from an answer that I did before I started.
Perhaps because you read plain english and interpret it in the most bizarre ways. docs: "group = shadow means that FreeRADIUS runs as group shadow" you: OK, "group = shadow" means that /etc/shadow is chgrp to "radiusd" What. The. Heck.
And due to that 'take two steps forward and half-dozen back', I've made it clear to my boss that FreeRADIUS, while it may work just fine, will be impossible to manage due to the horrible documentation and utter lack of help on the lists. I have removed the packages off my system and will be finding another method of communicating with these switches. I will also be unsubscribing from this list immediately.
Have fun. Alan DeKok.