Re: Freeradius-Users Digest, Vol 124, Issue 3
On Aug 3, 2015, at 11:45 PM, JCA <1.41421@gmail.com> wrote:
What's with the one letter acronyms? It just makes things harder to understand.
It's for conciseness - it's simpler to write R than "RADIUS server" every time. My apologies if this misled you.
It doesn't mislead. It's confusing and broken. "l33t" speak isn't useful, and is discouraged on this list.
It's not "l33t" speak; it's compact notation in order to keep things short and to the point. My apologies if that confuses you.
What you want is impossible to do. PAM is designed to do authentication. You CANNOT set group membership with PAM.
You can't, or you shouldn't?
I distinctly recall writing CANNOT.
What prevents one from writing a PAM module (or modifying an existing one) so that it will receive group information from the RADIUS server and modify /etc/group accordingly before returning to the caller?
Reality?
Writing to /etc/group is forbidden. For very good reasons.
Alan DeKok.
Well, I have just tried (as root, in CentOS) to edit /etc/group by hand, and I had no problems. Is it not the case that if the RADIUS PAM module runs as root, it will also be able to do so?
Hi,
Well, I have just tried (as root, in CentOS) to edit /etc/group by hand, and I had no problems. Is it not the case that if the RADIUS PAM module runs as root, it will also be able to do so?
what you seem to be after is a very specific local requirement - in which case a tool running as root could do that ...but noone would want to run such a tool outside your site... its would be a nice way to an interesting disaster....just look at the current 0-day exploit for MAC OSX that hijacks a tool running with root privileges :/ in short...if you WANT some form of plugin that edits /etc/group yourself..do it. alan
Well, I have just tried (as root, in CentOS) to edit /etc/group by hand, and I had no problems. Is it not the case that if the RADIUS PAM module runs as root, it will also be able to do so?
You are an administrator. You are a human. You have reasoning. A PAM module running as root should be jailed (through SELinux or other constraints). A PAM module is not human. A PAM module does not have reasoning. Just because *you* can, does not mean a program running as root should. In fact, a program running as root should *never* *ever* write to configuration files (such as /etc/group) unless a) they are the application's own configuration files, or b) prompted to through a configuration application by the administrator. Seriously... DO. NOT. DO. WHAT. YOU. INTEND. TO. DO. It's bad (terrible) practice. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
JCA -
Stefan Paetow