The vaunted documentation is just about the worst I've ever seen. It
goes in circles:
From modules/passwd:
> # An example configuration for using /etc/passwd. # # We do NOT
> recommend using the configuration below. See the "unix" # module,
> or the "pam" module for a cleaner way to get system passwords. #
> Using this configuration means that the server will find *only*
> those # passwords which are in /etc/passwd, and will *ignore* all
> of the # passwords in NIS, LDAP, etc. #
From modules/unix
Is the reason for not recommending the use of the passwd module
applicable here?
No.
The documentation assumes that you are able to read, interpret,
and make your own decisions about the validity of information.
> unix { # As of 1.1.0, the Unix module no longer reads, # or
> caches /etc/passwd, /etc/shadow, or /etc/group. # If you wish to
> cache those files, see the passwd # module.
So use the passwd module.
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. It's about setting the group the FreeRADIUS daemon runs as.
The FreeRADIUS daemon does not switch GID or UID when running in debug
mode, it continues with the GID and UID of the user which invoked it.
That's what the documentation is talking about.
>>>
>>> And setting "a+rw" on /etc/passwd and /etc/shadow is probaby
>>> the single worst thing you can do to your system.
Yes, setting a+rw would be completely idiotic, if you really don't
understand why, you should probably not have permission to make
such a change.
EVER.
>>> Rather than doing that, read raddb/radiusd.conf, it talks about
>>> issues with reading /etc/shadow, and describes suggested fixes
>>> won't
>> destroy your
>>> system.
>>>
>>> Honestly, I don't understand why it's so hard to read the
>>> configuration files.
Agreed.
>>>
>>> Alan DeKok. -
Radiusd.conf DOES NOT talk about issues with reading /etc/shadow.
ANYWHERE. PERIOD.
Because radiusd.conf is the main configuration file for the server,
why would it be cluttered with module specific configuration snippets
or advice...
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.
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.
An excerpt from the Fedora list: