[SOLVED] [Poll] Should future versions of Slackware include Linux-PAM?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
View Poll Results: Should future versions of Slackware include PAM?
Yes, future versions of Slackware should include PAM.
The nss-pam-ldapd documentation is a bit laconic. I tried to get some more details a while ago, but couldn't seem to find any.
Do you have any more specific documentation (notes, etc.) on the setup you use? I really would like nothing more than to stand corrected on this, as I'm currently using NIS for authentication, which is far from ideal.
Cheers,
Niki
To be honest, I think the nss-pam-ldapd documentation is quite sufficient. But that's my opinion from today's perspective. I have to admit it took me quite some time to grasp the concept of LDAP. If you don't know or haven't fully understood LDAP, nss-pam-ldapd can be hard to configure.
Can you tell what you think is missing from the documentation?
While LQ is the default forum of Slackware, yes, other communities outside of LQ should be considered as well for their input. There are plenty of newsgroups, irc, mailing-listings, alternate forums etc where Slackware users congregate. Excluding their input is rather obtuse.
The purpose of having it as SBO is to keep it completely optional for base. While this would allow for packages to be rebuilt against PAM using a Readme.Slackware file, there is the ability to also add a complete level of customization to tune packages for PAM as well, so partial or full rebuilds, or even pamified replacement packages could be allowed.
Even my custom Slackbuilds in my repo that have PAM support, have switches that allow for PAM also, but I do plan on reworking the scripts to be $PACKAGE-pam labeled for PAM supporting script variants.
This way you can, in the future, select to install ConsoleKit2-0.9.2-x86_64-1.txz or ConsoleKit2-pam-0.9.2-x86_64-1.txz depending on your needs.
The NO votes don't mean anything because the 100,000 Slackware users all around the world are not going to see this and vote. So what ever the YES count is, divide by 100,000 and that's you're result.
Everyone seems to use Slackware these days. Even folks who manage election vote counts in Central Africa.
To be honest, I think the nss-pam-ldapd documentation is quite sufficient. But that's my opinion from today's perspective. I have to admit it took me quite some time to grasp the concept of LDAP. If you don't know or haven't fully understood LDAP, nss-pam-ldapd can be hard to configure.
Can you tell what you think is missing from the documentation?
Mike
Two things come to mind.
1. Let's say you use a tool like LDAP Account Manager to create your users. How are your respective /home/<newuser> directories created?
2. While the setup you describe may work, it looks no better than Telnet security-wise.
LDAP is used to store users information. The pam_ldap component of nss-pam-ldapd is not used. nslcd connects to ldap server via gssapi to pull the user info. Kerberos manages passwords. pam_krb5 is used to authenticate the user and to obtain a ticket. And PAM is used because not every software that needs authentication supports kerberos, but virtualy everything supports PAM. Kerberos is also needed to make NFSv4 secure. Kerberos also provides the Single Sign On. Once pam_krb5 obtains a ticket Thunderbird for example can use gssapi to connect to smtp/imap. PAM is also needed for pam_winbind. PAM modules like access,group,nologin,tally,limits provide a unified way to control the access to the system and its resources.
NIS is a name service for UNIX directories like the passwd map, ethers map, etc. NIS is easy to setup and administer, scales reasonably well, is supported by nearly all forms of UNIX, and is thus very popular. Unfortunately, it is also completely insecure. Weakly encrypted passwords, as well as everything else, are sent over the network in the clear. NIS is difficult to firewall. Clients have no way to ensure that the server they are talking to is actually an official server. Of course this has been known for many years, but NIS is still widely used because a resonable alternative hasn't been available. Sun developed NIS+, but it was difficult to setup and administer (requiring a variety of difficult to remember commands and command-line options) and was adopted slowly (or not at all) by Open Source versions of UNIX.
In the last couple of years there has been a lot of buzz about LDAP. The Lightweight Directory Access Protocol was designed as a way to access directories containing all matter of information. It didn't take long for someone to consider storing UNIX information in a directory and using LDAP to access it. In theory this is a great idea, you can store all of the information you are used to storing in NIS (user ids, group ids, home directories, etc.) as well as other information like titles, office numbers, telephone numbers, etc. The system administrators can access the information they need, HR can get the info they need, etc. It is all stored in a central database, eliminating data replication. And most LDAP server implementations support pretty good security through SSL for authentication and transport encryption, fine grained access controls, etc.
So why hasn't LDAP already replaced NIS? It suffers many of the same problems as NIS+: it is difficult to set up a secure server, the command line utilities are numerous and take many obtuse options and client support has been slow to appear. Unfortunately Internet security has gotten to the point that we can no longer wait for a NIS replacement that is just as easy to manage. Hopefully this page will take some of the pain out of setting up a server and administering things. Client support exists if your client OS supports PAM and NSS, as well as a few other options if it doesn't.
What about Kerberos? Kerberos isn't necessary. You can store encrypted passwords in LDAP just like you can in NIS. It can even be made reasonably secure with SSL and proper access controls. However, you're still putting private information into a directory designed to hold public data. Kerberos was designed to solve this problem. It has been around for a long time, it is relatively easy to setup, and client support is fairly widespread. And Kerberos is even more secure than LDAP, because in a properly designed Kerberos environment even encrypted passwords are almost never transmitted across the network. Kerberos is also useful for things like secure NFS (coming in NFSv4). As such, this page is based on using Kerberos for authentication and LDAP for directory services. If you want to use LDAP for authentication, you'll want to look into pam_ldap.
The main reason, imo, to have PAM in base Slackware and not as an optional SBO, is to make sure it gets maximum exposure, for the better detection and weeding out of bugs.
The main draw of Slackware, to me, is its robustness. Robustness comes from thorough testing, both by the development team and the larger community. Without this testing, bugs are more likely to pass unnoticed into the SBO, which would have been caught and eliminated had it been in -current and an official Slackware release candidate.
The main reason, imo, to have PAM in base Slackware and not as an optional SBO, is to make sure it gets maximum exposure, for the better detection and weeding out of bugs.
The main draw of Slackware, to me, is its robustness. Robustness comes from thorough testing, both by the development team and the larger community. Without this testing, bugs are more likely to pass unnoticed into the SBO, which would have been caught and eliminated had it been in -current and an official Slackware release candidate.
exactly, also having PAM in an own component managed by someone is not good. If you bet your company buissness or even all of your free time on Slackware you need more security and less busfactor 1 constellations for available packages.
Me too. I actively dislike the idea of creating any sort of repositories that replace core system components. I will not use slackpkg-plus to keep packages like pam, kerberos, shadow, openssh, samba, openldap, vsftpd ... up to date. I am not interested in yet another Slackware fork. Adopting PAM will be one time effort and IMO is beneficial for the distribution. If PV thinks otherwise then so be it.
If it's in SBo or a Slackpkg+ repository it'll get exposure anyway. It's not required for the base, so leave it optional. There's no harm in you guys maintaining it separate from the main branch since you already do so. I'm fairly certain the effort to add your repository and a URL on a webpage to the slackpkg+ config and the Slackwiki shouldn't take an act of God or Bob to implement.
I maintain my own stuff, limited it may be, but I maintain it.
The main reason, imo, to have PAM in base Slackware and not as an optional SBO, is to make sure it gets maximum exposure, for the better detection and weeding out of bugs.
The main draw of Slackware, to me, is its robustness. Robustness comes from thorough testing, both by the development team and the larger community. Without this testing, bugs are more likely to pass unnoticed into the SBO, which would have been caught and eliminated had it been in -current and an official Slackware release candidate.
yes, ofc
but this is special
bugs from networked security... whatever they are called, from what i see are mostly from bad configuration
by that reasoning, a very good documentation would be the most important thing
users that do not need these kinds of things, i doubt could properly debug them themselves
nor, even more, would want to learn what all this words related to it even mean
Since the OP does not actually use Slackware, I am proposing this thread/poll be renamed to:
"Should future versions of MLED include Linux-PAM?"
MLED is Slackware with a few extra packages.
I admit I'm a bit puzzled by some users' latent or outright hostility in this thread. May I remind you that I'm only discussing the possible inclusion of a feature that would 1. go unnoticed by the general user crowd 2. allow admins to implement some enterprise-class features using Slackware (instead of RHEL/CentOS/SLES/Debian).
I was curious about your take on this, so I included three sensible options, and you're free - and welcome - to answer according to your preferences. On the other hand, if the mere discussion of this question is a problem for you, I suggest you buy a punching bag to vent your frustration.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
