Old school: FreeRADIUS and NIS

[Alan DeKok]

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.