Debian Weekly News [LWN.net]

Debian Weekly News

Posted May 18, 2005 1:17 UTC (Wed) by syndicate (guest, #27535)
Parent article: Debian Weekly News

I think the first entry just goes to show you how broken our authentication system is. Althought I don't have any solutions and I am just complaining, it irks me to see that /etc/passwd is still this broken in terms of application support and methods of determining an account status.

to post comments

Debian Weekly News

Posted May 18, 2005 6:46 UTC (Wed) by jwb (guest, #15467) [Link] (2 responses)

It's even worse than it appears. To many people, "disabling" a login means setting the shell to /bin/ false or some other unobvious act. PAM has never understood the difference between authentication - does the user claim to have an account, and can they prove it? - and authorization - is the authenticated user allowed to do this thing? Suppose you want to add a user, identified by an RSA key, who can send mail via SMTP, retrieve mail via IMAP, send and receive files with FTP, access a private website, but not login via SSH or do any other thing. With your average Linux system this would either be impossible or very inconvenient. There's a lot of room for improvement in the auth/authz department.

Debian Weekly News

Posted May 18, 2005 6:56 UTC (Wed) by khim (subscriber, #9252) [Link]

PAM never difference between authentication and authorization since it's useless (and dangerous!) cruft for PAM. It will not even differentiate between situation when user registered in system and when the same user typed wrong password - this is by design.

And far as for user "identified by an RSA key, who can send mail via SMTP"... this is bigger problem then you can think: pam_listfile will not help here at all. You need some way to deliver that RSA key to PAM! And since most web protocols have no support for this...

Debian Weekly News

Posted May 19, 2005 15:34 UTC (Thu) by mmarsh (subscriber, #17029) [Link]

My understanding was that PAM is exclusively an authentication mechanism. Authorization (and audit, to complete the gold standard) is a separate thing, to be verified once you know *who* a principal is. The authorization mechanism in Linux is generally pretty simplistic, unless you add something like SELinux. I'd bet that SELinux could be used to set up the rights that you mention, though how easy it would be is another matter. For instance, if you allow FTP, does that give the user a way to get a shell?

There's definitely room for improvement, but then isn't there always?