LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   slackware 15 and pam (https://www.linuxquestions.org/questions/slackware-14/slackware-15-and-pam-4175483168/)

zerouno 11-02-2013 11:56 AM

slackware 15 and pam
 
I'm not a pam lover, but I think tha the next stable release (14.2 or 15.0) should be linked to pam.

Slackware already contains pam, in /extra, but is only for additional packages. I can't use ssh with pam.
Really, I don't like pam, but some authentication schema (ldap for example) does not work without it

Alien Bob 11-02-2013 12:02 PM

Slackware 14.1 will not have PAM in its /extra directory. The pam library was needed in Slackware 14.0 for google-chrome, but that requirement has been dropped, so the pam stuff was removed a while ago.

As for Slackware 15... who says there won't be a 14.2 , 14.3, ...? And Using PAM with LDAP is left as an exercise for the reader.

Eric

ReaperX7 11-02-2013 06:14 PM

PAM really is a headache and is known to break systems. It's best to leave it out of a system unless it's a truly required dependency.

willysr 11-02-2013 07:54 PM

Although MATE also need PAM for mate-screensaver package in order to be able to lock the desktop (and this is a very important feature for most users), we decided not to put PAM in the base/extra directory, but placed it on testing/ and we don't build the package on this and leave it to users if they want to use it.

ethoms 07-14-2014 02:46 AM

I think there may be another way to get ldap authentication without dirtying hands with PAM. It seems like it has a static implementation of PAM included inside it, enough to do ldap auth. It is in salckbuilds: http://slackbuilds.org/repository/14...nss-pam-ldapd/

I haven't had time to look at it yet, so i can't say much about it. However it doesn't seem to depend on anything outside the base, which sounds like it could make a fairly clean solution for ldap auth.

Sorry if this thread is too old for my post, but somebody may stumble on it and it may be useful.

ReaperX7 07-14-2014 08:32 PM

OpenLDAP only requires PAM if compiled for it, otherwise it doesn't use or need it. It's entirely optional. PAM takes a lot to setup and configure as well as many packages require a PAM configuration script.

Unless you seriously want to play around with PAM, go right ahead, but if you get locked out of root for whatever reason, don't say you weren't warned.

Slax-Dude 07-15-2014 06:27 AM

Do the reasons that took PV to dislike PAM back in the day still apply today?
(I guess only PV can really answer this one hehehe)

Ser Olmy 07-15-2014 07:45 AM

It might be time to consider including PAM, since it does indeed offer some very useful functionality. On the other hand, it's really easy to retrofit PAM to a Slackware system (install PAM, make create a system-auth file in /etc/pam.d, rebuild shadow), so I'm not sure the need is all that great.
Quote:

Originally Posted by ReaperX7 (Post 5057329)
PAM really is a headache and is known to break systems. It's best to leave it out of a system unless it's a truly required dependency.

I'm not trying to start an argument here, but what kind of breakage have you seen? Most of my Slackware systems are PAM-ified and I've been doing that for years. I've had no issues so far.

ReaperX7 07-15-2014 08:19 PM

I've seen things as bad as accounts becoming completely locked to where logging in is forbidden, even to the root user resulting in a total lock-out requiring a chroot via a rescue disk, and a lot of work to reset PAM back to TRY and reset PAM back to the defaults.

Don't get me wrong, it's good for security purposes, and I've seen proper implementations go off smoothly, but PAM isn't something you take lightly as an admin, nor just recklessly deploy to the masses without considering the consequences and the likelihood of seeing topics and emails about someone being locked out of root or a secondary login, or administrative user account being disabled.

To be perfectly honest with you, PAM is just one of those packages you either build around and wait for chaos to ensue, or leave as optional and have less to worry about in the long-term.

As someone who's dealt with PAM, I highly recommend against using it honestly, unless you are thoroughly prepared for the possible fallout. Besides, in reality shadow+cracklib works just as well along with other security protocols and implementations.

You really have to weigh the pros and cons of packages like PAM from the viewpoint of a distribution maintainer and also a system administrator before you consider deploying them. It's the old argument of, "If I could, would I, and if I would, should I?"

a4z 07-16-2014 12:16 AM

FUD?
I think all distributions that I use beside Slackware ship PAM.
I have never been locked out.
just because I did not do something equally stupid than rm -rf or was it just luck?

ReaperX7 07-16-2014 02:12 AM

It's not FUD sadly. It would be nice if PAM was a software package that did have a fail-safe to prevent accidents, but it doesn't.

There are many reasons both to include and not to include it, but sadly the reasons anyone can list for not including are fairly bad such as the account lock-out issue which can actually result from anything. Plus there is the problem that if your system is compromised, someone can edit the config and totally lock you out taking over control of your system entirely. It's worst case scenario, but still it has to be considered.

Slax-Dude 07-16-2014 04:50 AM

Quote:

Originally Posted by ReaperX7 (Post 5204581)
Plus there is the problem that if your system is compromised, someone can edit the config and totally lock you out taking over control of your system entirely.

??
And if you don't use PAM you are somehow immune to these things?

ReaperX7 07-16-2014 04:22 PM

Doesn't matter if you use it or not. If your system is compromised, it's just yet another tool that a hacker can use against you.

I'm done arguing on this point as honestly it's stupid. Patrick left it out for a damned good reason, and whether or not that reason was touched on or not in this topic, remains what it is. It was left out for a damned good reason.

It is what it is, so take that in or out of context however you like. Patrick has his reasons, and in my systems, I have my own. If they aren't the same or the same doesn't matter. PAM is entirely optional to UNIX as a whole, has never been a requirement, and it's set up and implementation varies system to system for whatever purpose. If brand X distro wants to include it, then that's their baby.

dugan 07-16-2014 04:31 PM

Quote:

Originally Posted by Slax-Dude (Post 5204127)
Do the reasons that took PV to dislike PAM back in the day still apply today?
(I guess only PV can really answer this one hehehe)

He has, back in 2010.

Quote:

Originally Posted by volkerdi (Post 4182564)
That was true perhaps a decade ago, around the time I made the now infamous comment about "PAM == SCAM". Back then, many applications either had to be patched to add PAM support, or if they had PAM support it probably needed additional patches to work right. These days, the opposite is just as likely to be true. Especially with things such as ConsoleKit and polkit (which we pretty much have to include in order to provide a functional desktop), we are finding that the non-PAM code is not as well tested, and that we've had to patch things in order to work with the traditional shadow based authentication. Eventually these developments are likely to force our hand with regard to PAM (but not in the immediate future).


T3slider 07-16-2014 05:30 PM

Quote:

Originally Posted by ReaperX7 (Post 5204581)
... the account lock-out issue which can actually result from anything.

So ANYTHING can cause PAM to completely break? Obviously PAM will only break if something is done to break it. In normal configuration/usage it would do just fine. Don't blame the software for user error.
Quote:

Originally Posted by ReaperX7 (Post 5204581)
Plus there is the problem that if your system is compromised, someone can edit the config and totally lock you out taking over control of your system entirely. It's worst case scenario, but still it has to be considered.

Something like the following (or a variation of it) would probably lock you out with just plain shadow (DO NOT TRY THIS AT HOME):
Code:

# sed -i 's/^\([^:]*:\)\([^:]\+\)\(:.*\)/\1!\3/' /etc/shadow
I don't see how this is any different than breaking PAM configuration. If someone has access to your machine and can get elevated privileges then of course they could break your installation and prevent you from logging in. What a silly argument.

ReaperX7 07-16-2014 05:57 PM

So make a good point as to WHY it should be included if it's such grandiose a software package that we "have to have it" on some shape, form, or level because what Patrick said in 2010 was what I said in BOLD text above. It's not a required dependency!

Arkerless 07-16-2014 09:30 PM

Quote:

Originally Posted by T3slider (Post 5205001)
So ANYTHING can cause PAM to completely break? Obviously PAM will only break if something is done to break it. In normal configuration/usage it would do just fine. Don't blame the software for user error.

Even if it is 'user error' at some level, a package that adds lots of opportunities for critical breakage that were not there before probably does deserve some of the blame.

Quote:

Something like the following (or a variation of it) would probably lock you out with just plain shadow (DO NOT TRY THIS AT HOME):
Code:

# sed -i 's/^\([^:]*:\)\([^:]\+\)\(:.*\)/\1!\3/' /etc/shadow
I don't see how this is any different than breaking PAM configuration.
The difficulty and likelihood of it happening would seem the main difference.

From my point of view, PAM adds unnecessary complexity and lots of attack surfaces. Do you have complex attack surfaces without PAM? Very likely. Still makes sense to avoid as much of it as you can.

ReaperX7 07-16-2014 09:52 PM

Yes, and because an ongoing trend in Slackware is to avoid unnecessary packages such as entirely optional dependencies when possible, I highly doubt PAM will ever become a required package to have. No software across the UNIX spectrum even requires it at all.

The complexity of PAM makes it problematic by it's very nature. Look at the packages in BLFS that require a PAM setup if PAM is compiled in and built against if and when you have time. The amount of setup required is often near monotonous levels, plus the fact that BLFS's PAM is trying to set a default that has some level of ability to work without issues and control things securely, is not even secure by nature.

Not to mention even updating PAM as a package can be extremely dangerous as well. here's an excerpt from BLFS's PAM page:

Quote:

If you have a system with Linux PAM installed and working, be careful when modifying the files in /etc/pam.d, since your system may become totally unusable. If you want to run the tests, you do not need to create another /etc/pam.d/other file. The installed one can be used for that purpose.

You should also be aware that make install overwrites the configuration files in /etc/security as well as /etc/environment. In case you have modified those files, be sure to backup them.
Plus the fact PAM accepts 3rd party modules makes you wonder how much control vs usability you want.

Add in the fact this guidebook:

http://www.linux-pam.org/Linux-PAM-h...x-PAM_SAG.html

Really covers a ton of information that may or may not be required, useful, or even remotely of interest to a workstation level, laptop, desktop, or server system, makes you consider the fact: do you, or do you not need PAM?

Plus there's also the problematic anyone can face that could render a system disabled as well. A file system error. Truth be told, you or anyone else can never know when or if a file system error can occur. Now granted with file systems like JFS, EXT4, ZFS, and such we might not have an issue, but then again, you never how what can happen with a kernel update. Bad code could slip through, highly unlikely, but it has happened, and a file system could get corrupted, and then what if the PAM files get knocked out?

The point is, PAM is NOT some software package that you take for granted and just willy-nilly toss it in for the sake of having it. It is software that has to be handled with care, careful planned around, and deployed safely and correctly.

Being careful with software is one thing, but being foolish with software is another.

kikinovak 07-17-2014 01:32 AM

The non-inclusion of PAM is one of the reasons I'm currently switching my servers from Slackware to Ubuntu LTS. Only Bob knows how sad that makes me.
  1. Centralized LDAP user authentication is not possible without PAM.
  2. Some say it's possible, but this procedure is documented nowhere.
  3. I'm not counting the bits of stale and/or false information, like the AOLS FAQ.
  4. This leaves me with NIS, which isn't exactly state of the art security-wise, and which is very limited.

Cheers,

Niki

Edit PS: to be accurate, it *is* possible, but only by jumping through burning loops, e. g. rebuilding openldap, building Linux-PAM and then rebuild a few dozen core packages. I know Vincent Batts has a project for doing this, but this is not an option.

GazL 07-17-2014 03:49 AM

I don't need PAM, so have no particular axe to grind, other than a general worry that the non-PAM execution paths through pkg-shadow are becoming increasingly unused, crufty, and liable to contain unidentified and unresolved issues. Remember Mancha's " Revert CVE-2005-4890 fix" needed to restore 'su -c' functionality? If I remember rightly, that issue was fixed properly in the PAM-enabled shadow, but they had to break functionality in the non-PAM shadow in order to close that potential tty hijacking issue. This may have been resolved properly by now (I've not been following shadow development very closely for a while), but its an example of the sort of thing I'm talking about here.

Clearly as Niki's post above shows, some people do need PAM features, and while its all well and good leaving it as an exercise for the user, if its absence is driving people away, then personally, I think its time to reconsider it.

Slax-Dude 07-17-2014 04:43 AM

Quote:

Originally Posted by dugan (Post 5204972)
He has, back in 2010.

Yes, but that was PV 4 years ago commenting on what he thought of PAM 10 years before that.
Not exactly "current" :)

I'm not disputing the merit of the decision of not including PAM at the time (I'm sure the reasons were valid then), but I'd very much like to know if those reasons are still valid today.

In the IT world 4 years is a long time and PAM has been around for 14 years (and is still active)... so I expect that most of its major problems have been dealt with.

And as kikinovak said, not having a solid centralized login facility is a deal breaker in enterprise.
I use Slackware on some of my workplace servers, but can't sell it to my boss as a desktop (not just because centralized auth is missing, but that is one of the major points).

ReaperX7 07-17-2014 06:14 AM

Not having PAM for centralized logins shouldn't be a deal breaker for Enterprise even in Slackware's case.

To be honest, if you absolutely require PAM, you have all the tools necessary to build an on-site package repository to rebuild PAM-enabled packages using the SlackBuilds from the sources. You don't have to distribution-hop, but you shouldn't have to be hand-held either. The PAM SlackBuild is still in the 14.0/extra/source repository, you can update it on your own, track down which packages need rebuilding, and then install PAM and rebuild the required packages, so honestly you have no excuses.

In fact if you're running a server at the Enterprise level you should already be using an on-site repository with packages built to the company's IT Security Specifications anyway, not general release software.

kikinovak 07-17-2014 06:28 AM

Quote:

Originally Posted by ReaperX7 (Post 5205239)
To be honest, if you absolutely require PAM, you have all the tools necessary to build an on-site package repository to rebuild PAM-enabled packages using the SlackBuilds from the sources. You don't have to distribution-hop, but you shouldn't have to be hand-held either. The PAM SlackBuild is still in the 14.0/extra/source repository, you can update it on your own, track down which packages need rebuilding, and then install PAM and rebuild the required packages, so honestly you have no excuses.

A few years back, I went to see a friend of mine, a writer who lives in a very remote village up in the mountains in Austria. He asked me if I wanted to eat fish for dinner, and when I accepted enthusiastically, he grabbed his fishing gear, and we went to a nearby river. He's an experienced fisher, and after an hour or so, we had four big trouts in the bucket. As soon as we arrived home, he started cooking the fish, using potatoes and herbs from his garden, and the meal was delicious.

I like a similar approach for other things in life, operating systems for example. But I think that if my friend had asked me to raise some trouts first, I would politely decline and suggest we simply go to a restaurant instead. While I am a very patient person and like to experiment and fiddle a lot, I'm not the guy who builds cathedrals out of matchsticks or who crams ocean steamboats into bottles for relaxing.

Cheers,

Niki

Slax-Dude 07-17-2014 06:47 AM

Quote:

Originally Posted by ReaperX7 (Post 5205239)
To be honest, if you absolutely require PAM, you have all the tools necessary to build an on-site package repository to rebuild PAM-enabled packages using the SlackBuilds from the sources. You don't have to distribution-hop, but you shouldn't have to be hand-held either.

I'm not saying I'm incapable of doing so, I just wont spend my already tight schedule tracking upstream packages for updates.
If I liked doing that I'd go LFS and be done with distros altogether.
I'm a sysadmin in 2 SMBs but distro maintainer is not in the cards for me :)
Slackware is a tool (one of my favorites) in my tool-belt. If I can use it, I will... but I won't force a squared peg into a round hole, nor do I have the time/patience to round that peg with sand-paper ;)

Quote:

Originally Posted by ReaperX7 (Post 5205239)
so honestly you have no excuses.

Oh, but I do :)
(see above)

Quote:

Originally Posted by ReaperX7 (Post 5205239)
In fact if you're running a server at the Enterprise level you should already be using an on-site repository with packages built to the company's IT Security Specifications anyway, not general release software.

Who told you I don't?

ReaperX7 07-17-2014 07:14 AM

Those who are without patience shall have nothing whilest those with patience shall have all they need.

Slackware is a tool, yes, but it up to you the user of said tool to learn to use the tool given to you not just correctly, but within acceptable purposes. Slackware, as it is well known, is not a hand-holding distribution. It gives you a foundation regardless of how much you install, but the rest is up to you.

As a system administrator who operates a repository, you should already be developing those packages, so therein you honestly have a very flimsy excuse, even though it is one. Time is critical, but I've seen many an admin in my day wasting time on Facebook, Twitter, Tetris, etc. while they could be spending that time performing those tasks and others. If compiling all those packages is so time consuming, make time, take time, and draft a script to do all the required work while you're gone for the day, night, weekend, whatever.

Sometimes even a square peg may require sanding down to fit into a square hole as well, then again sometimes there are no square holes for your square peg. I should know. There's a nice round peg sitting in a square hole in my signature below.

kikinovak 07-17-2014 08:50 AM

Quote:

Originally Posted by ReaperX7 (Post 5205260)
As a system administrator who operates a repository, you should already be developing those packages, so therein you honestly have a very flimsy excuse, even though it is one. Time is critical, but I've seen many an admin in my day wasting time on Facebook, Twitter, Tetris, etc. while they could be spending that time performing those tasks and others. If compiling all those packages is so time consuming, make time, take time, and draft a script to do all the required work while you're gone for the day, night, weekend, whatever.

ReaperX7, I'm the only one in my household who earns money, and I do this by running a small company (http://www.microlinux.fr). I know how to be organized, I don't have a television, and this year I had exactly 5 (five) days of holidays. Of course I could very well make time, stop my climbing and hiking activities, tell my girlfriend I have no time to go for a walk with her because I have to rebuild half of Slackware against Linux-PAM.

NeoMetal 07-17-2014 09:41 AM

I built PAM and rebuilt shadow, su, sudo and so on, in my current Slack installation back in January or something when another thread about PAM/LDAP came up. I've been authenticating against AD since then with no problems, the initial setup of everything took some research but wasn't too terrible . At this point I think the flexibility of having PAM as part of default Slack would probably be beneficial. Alternatively if anyone is considering creating some slackbuilds or something to semi-automate the process of integrating PAM and the basic packages that would need it, I'm down to help

Arkerless 07-17-2014 02:13 PM

I think if I were in the situation of absolutely having to have PAM running somewhere, I would want to do it in a virtual machine, hosted on a machine without it. Perhaps I would even run corebuntu in the VM, just to save time. But I would not want it to be part of the distro I am running on the iron.

Ser Olmy 07-17-2014 02:22 PM

Quote:

Originally Posted by NeoMetal (Post 5205318)
I built PAM and rebuilt shadow, su, sudo and so on, in my current Slack installation back in January or something when another thread about PAM/LDAP came up. I've been authenticating against AD since then with no problems, the initial setup of everything took some research but wasn't too terrible . At this point I think the flexibility of having PAM as part of default Slack would probably be beneficial.

This.

Unless it's going to cause some major breakage that I'm not aware of, I think the question when it comes to including PAM should be "why not" rather than "why". The advantages of PAM are pretty obvious, and I believe the security issues that prompted PV to keep PAM out of Slackware have long since been resolved (please correct me if I'm wrong here).

Woodsman 07-17-2014 03:13 PM

Quote:

Of course I could very well make time, stop my climbing and hiking activities, tell my girlfriend I have no time to go for a walk with her because I have to rebuild half of Slackware against Linux-PAM
While I suspect the statement was tongue-in-cheek with respect to the requirement to build "half" of Slackware, I get the point about the additional overhead to include PAM in Slackware. I am curious how much change is required to include PAM in Slackware. PAM is a de facto standard package in almost all other distros. I have no opinion on that inclusion but I doubt there are serious usability problems with PAM or distro maintainers would have not included PAM as a de facto standard package. And that several Slackware users in the enterprise do PAM-ify their Slackware systems is revealing to some degree and that the exclusion of PAM requires a Slackware enthusiast active in the enterprise to choose a different distro also is revealing.

Quote:

the initial setup of everything took some research but wasn't too terrible
Perhaps then this thread could change focus to provide the details necessary to add PAM to Slackware? Perhaps that kind of approach would help the development team with experimenting and testing?

Also, if PAM was added to Slackware, could the defaults be to have PAM disabled such that only those who need PAM need to take active steps to enable? That is, can PAM be installed but not be used or required? Or is including PAM all-or-nothing?

Arkerless 07-17-2014 03:31 PM

Quote:

Originally Posted by Slax-Dude (Post 5205214)
In the IT world 4 years is a long time and PAM has been around for 14 years (and is still active)... so I expect that most of its major problems have been dealt with.

I would humbly suggest your expectations sound unrealistic. The major problems were mostly design issues at heart. The design has not been changed. No matter how long you polish the driftwood, no matter how shiny you get the frequently touched parts, it's still always going to be driftwood, and will never transmute to ivory.

NeoMetal 07-17-2014 03:42 PM

Quote:

Originally Posted by Woodsman (Post 5205506)
While I suspect the statement was tongue-in-cheek with respect to the requirement to build "half" of Slackware, I get the point about the additional overhead to include PAM in Slackware. I am curious how much change is required to include PAM in Slackware. PAM is a de facto standard package in almost all other distros. I have no opinion on that inclusion but I doubt there are serious usability problems with PAM or distro maintainers would have not included PAM as a de facto standard package. And that several Slackware users in the enterprise do PAM-ify their Slackware systems is revealing to some degree and that the exclusion of PAM requires a Slackware enthusiast active in the enterprise to choose a different distro also is revealing.


Perhaps then this thread could change focus to provide the details necessary to add PAM to Slackware? Perhaps that kind of approach would help the development team with experimenting and testing?

Also, if PAM was added to Slackware, could the defaults be to have PAM disabled such that only those who need PAM need to take active steps to enable? That is, can PAM be installed but not be used or required? Or is including PAM all-or-nothing?

I tried to outline what was needed and where I found some of the info in my post here: http://www.linuxquestions.org/questi...ml#post5108904

(It was kind of a rushed stream of consciousness thing but hopefully it conveys the overall process, I can try to clean it up and walk through it again to see if it makes sens to even me several months on. Maybe Ser Olmy or V Batts might be able to clarify some things better than I could as that was my first time really delving into it :O )

ReaperX7 07-17-2014 04:19 PM

PAM is fairly much all-or-nothing as if added, it becomes a hard dependency for programs unless the PAM argument is turned off at compile-time. Some programs have this, and some do not.

The best argument I could give to find out how many packages would require PAMification, would be to thoroughly read through BLFS as a kind of guidebook, and see which packages they have that utilize PAM, that way you have an idea of what requires PAM if added, maybe in Slackware.

There is another option I'm surprised NOBODY failed to mention/ask about.

/extra

Just as AlienBOB has his multilib directory, though it's not in Slackware officially, any and all packages that require PAM could effectively be given a /extra/pam-packages directory either on disk or on the Slackware FTPs, and just maintained that way either with packages or ready-to-use SlackBuild scripts.

kikinovak 07-17-2014 04:38 PM

Quote:

Originally Posted by ReaperX7 (Post 5205528)
There is another option I'm surprised NOBODY failed to mention/ask about.

/extra

This has been discussed, though a bit under the radar on IRC. AlienBob suggested exactly this, an extra repo similar to his multilib repo. Only problem is you'd have to find someone to maintain it.

kikinovak 07-17-2014 04:56 PM

Quote:

Originally Posted by Woodsman (Post 5205506)
And that several Slackware users in the enterprise do PAM-ify their Slackware systems is revealing to some degree and that the exclusion of PAM requires a Slackware enthusiast active in the enterprise to choose a different distro also is revealing.

This will be a bit off-topic, but there's more to it than that. The absence of PAM is only one factor in my migration, but there are some others where Slackware is not necessarily at fault. A significant part of my job is teaching, and the last three requests I had from businesses were all specific for Ubuntu Server, which seems to be extremely popular, at least here in France. So I try to meet the client's expectations, and I'm an eat-your-own-dog-food type of admin/teacher. Besides that, there's an unexpected problem using Slackware in France for teaching, it's that most of the folks in France are really bad at understanding even the most basic english. During the last class I taught, there were some vocal protests why we weren't using a translated version of Linux. An entirely different factor, and this is completely unexpected, I've discovered Elementary OS' Pantheon desktop, which is nothing less than the perfect Linux desktop environment I've always been looking for. Right now it's only available for *buntu, Arch and Gentoo, but maybe one day someone will port it to Slackware. Last but not least, I find myself more busy and with less time on my hands these last months, so it's in effect much easier and less time-consuming to setup half a dozen of PPA's on Elementary in order to have a full-fledged workstation with applications galore. For the time being, I had to put my MLED project to sleep, and I don't know when I can pick it up again.

That being said, Slackware will always have a warm place in my heart.

Niki

Woodsman 07-17-2014 05:40 PM

Quote:

This will be a bit off-topic, but there's more to it than that.
Thanks for sharing. I am in a similar predicament, as you already know from other threads.

Quote:

PAM is fairly much all-or-nothing as if added
Could the defaults be configured to be as transparent as possible, almost to the point that those who do not need PAM would almost not notice?

Quote:

This has been discussed, though a bit under the radar on IRC. AlienBob suggested exactly this, an extra repo similar to his multilib repo.
Is the idea that all of the /extra packages would be direct drop-in replacements? Just use upgradepkg?

ReaperX7 07-17-2014 06:51 PM

The idea is yes, they would be drop-in replacements... such as:

OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz

This way, PAM is not just optional on the system as a whole, but so are the packages, their configuration scripts, etc.

Didier Spaier 07-18-2014 02:00 AM

Quote:

Originally Posted by ReaperX7 (Post 5205580)
The idea is yes, they would be drop-in replacements... such as:

OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz

This way, PAM is not just optional on the system as a whole, but so are the packages, their configuration scripts, etc.

That would mean more maintenance. I'm not sure that the Slackware crew can afford that.

ruario 07-18-2014 02:43 AM

Quote:

Originally Posted by ReaperX7 (Post 5205580)
OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz

Just a minor nitpick but that suggested name does not follow Slackware package naming conventions. Issuing "echo [full package name] | rev | cut -f4- -d- | rev" should result in the short package name (without the version number, architecture, build tag and extension). Your suggested naming breaks this.

More likely it would be openssh-pam-version-architecture-buildtag.txz (I also lower cased OpenSSH, since this is how the package is named in the official Slackware packages).

ruario 07-18-2014 02:58 AM

If I had a vote (which obviously I don't), I would suggest Slackware adopts PAM. After several years maturation it has obviously got to the stage where it is workable (given pretty much every major distro has a adopted it). Additionally I think it makes life far more difficult not having it, for those that need it in production environments.

P.S. Four years back volkerdi had already hinted at the possibility of Slackware with PAM one day.

Quote:

Originally Posted by volkerdi (Post 4182564)
That was true perhaps a decade ago, around the time I made the now infamous comment about "PAM == SCAM". Back then, many applications either had to be patched to add PAM support, or if they had PAM support it probably needed additional patches to work right. These days, the opposite is just as likely to be true. Especially with things such as ConsoleKit and polkit (which we pretty much have to include in order to provide a functional desktop), we are finding that the non-PAM code is not as well tested, and that we've had to patch things in order to work with the traditional shadow based authentication. Eventually these developments are likely to force our hand with regard to PAM (but not in the immediate future).

I wonder if we are any closer now or not?

a4z 07-18-2014 03:43 AM

Quote:

Originally Posted by ReaperX7 (Post 5205580)
The idea is yes, they would be drop-in replacements... such as:

OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz

This way, PAM is not just optional on the system as a whole, but so are the packages, their configuration scripts, etc.

and then we re-write all packaging tools to respect the new namings and deal with them.

--
sometimes it have the feeling that some opinions are more based on fundamentalism than on facts.

ruario 07-18-2014 04:35 AM

Quote:

Originally Posted by a4z (Post 5205768)
and then we re-write all packaging tools to respect the new namings and deal with them.

The idea would work assuming there was someone to maintain them. He just got the naming wrong but that part is fixable.

Doesn't have to be in extra though, any interested party with enough time on their hands could do this.

kikinovak 07-18-2014 07:56 AM

Quote:

Originally Posted by ruario (Post 5205754)
If I had a vote (which obviously I don't), I would suggest Slackware adopts PAM.

+1.

Woodsman 07-18-2014 01:34 PM

Quote:

That would mean more maintenance. I'm not sure that the Slackware crew can afford that.
I am guessing Pat and the team have many script wrappers to automate Slackware maintenance, so perhaps not that much additional maintenance. :) I suspect the biggest hurdle is introducing PAM into Current so Current users can start kicking tires and revving engines.

Quote:

Just a minor nitpick but that suggested name does not follow Slackware package naming conventions.
Yeah, but we all got the point. :) Perhaps just replace "SBo" with "PAM" to make the drop-in packages.

Quote:

Doesn't have to be in extra though, any interested party with enough time on their hands could do this.
Perhaps SBo for 14.2 and after that trial run pull into 15.0?

Quote:

If I had a vote (which obviously I don't), I would suggest Slackware adopts PAM.
Yeah, +1 here too. Not saying PAM is a Good Thing or the Right Stuff, but as Pat shared four years ago, the infamous PAM = SCAM days are long gone. I have no personal need for PAM, but adding PAM is one less item to use against Slackware when people choose a distro. Sometimes swimming against the tide forces uncomfortable decisions and adding PAM probably is a reasonable decision nowadays.

abesirovic1 07-22-2014 10:54 AM

For educational purposes, why is PAM bad (I'm not trolling, I'm just curious)?

ReaperX7 07-22-2014 10:02 PM

PAM is safe as long as you don't screw with any configuration files, and your file system doesn't corrupt and knock out a possible critical file of PAM.

However, due to the fact in the post install phase, some PAM configuration scripts have to be created, setup, edited, and such, it's hard to say which configuration would overwrite, delete, remove, or possibly foul-up a needed configuration file. As as result, you'd have to have a premade set of configuration files to do everything with the proper permissions, but becasue no two setups and systems are the same, knowing what would be best as a default might not work for user A the same as user B.

Plus, several file systems Slackware uses and supports are know to have issues such as ReiserFS, XFS, and BtrFS respectively.

Here's an example:

/etc/pam.d/other might require as a default:

Code:

auth            required        pam_unix.so    nullok
account        required        pam_unix.so
session        required        pam_unix.so
password        required        pam_unix.so    nullok

but another program (such as shadow) may require:

Code:

auth        required        pam_warn.so
auth        required        pam_deny.so
account    required        pam_warn.so
account    required        pam_deny.so
password    required        pam_warn.so
password    required        pam_deny.so
session    required        pam_warn.so
session    required        pam_deny.so

Now you have a conflict of configurations. As a result, you have to either use a default which may not work securely, or you have to use something that's more secure and restrictive, but if the package isn't there to require the restrictive edit, what do you do? Use the default, or use the edit? And if you have a script edit the other config, when you uninstall, does it leave the configuration as-is, change it, or delete it, and what if another program already made other changes? Now what do you do?

To be honest, PAM's configurations are what the problem is. There's no real way to set a viable default that can cover all the system possibilities. What if you install shadow but not OpenSSH? Do you need the setup for OpenSSH? What about xinetd? If xinetd requires it's own special configuration, what if another program uses it and it gets deleted or mishandled?

Yes, PAM adds that would-be nice layer of security and it would be beneficial for Slackware to have it, but PAM requires planning by the end user, lots of planning, and often at times, there is no viable default that can be generally useful to all.

a4z 07-23-2014 01:09 AM

Quote:

Originally Posted by ReaperX7 (Post 5208160)
To be honest, PAM's configurations are what the problem is. There's no real way to set a viable default that can cover all the system possibilities. What if you install shadow but not OpenSSH? Do you need the setup for OpenSSH? What about xinetd? If xinetd requires it's own special configuration, what if another program uses it and it gets deleted or mishandled?

and how do other distributions solve this?
and do they have problem like this?
I mean PAM is shipped since years on all distributions, this is millions of installations.
if it would be such a problem than there would be very many problem reports, do they exist?

ReaperX7 07-23-2014 03:44 AM

I wouldn't know honestly. PAM varies package to package, system to system, user to user. To be honest you could have any number of configurations on any number of systems, so to define a true default is improbable. Even LFS's implementation varies package to package that requires a configuration.

What Fedora does might not be the same as LFS and what LFS uses may not be good for another distribution. The point is, there are too many variables to define a default, even for Slackware.

What would be good for Slackware and what might not? What is good for one package and not another? What is acceptable and what isn't? Should PAM start with less secure or more secure? What packages should be compiled against PAM and what shouldn't?

Ask a million questions, get a million to the power of a million answers. In this compared to PAM, we have no idea of know what would be good for what.

Arkerless 07-23-2014 04:03 AM

Quote:

Originally Posted by abesirovic1 (Post 5207903)
For educational purposes, why is PAM bad (I'm not trolling, I'm just curious)?

Considering I have been very successful at avoiding the thing for years I am not the best person to answer this concretely, but I will give it a shot at the abstract level. It's quite possible that any specific criticisms I might recall from the last time I tried to configure it are ancient history at this point, without any fundamental change in the architecture I would still consider it unwanted.

First off, system-critical processes, particularly ones directly concerned with security, shouldnt rely on shared modules. There are several serious issues with that, some obvious some subtle, and correct me if I am wrong but I recall PAM was designed to use shared modules anyway, and I dont recall that ever being changed.

Secondly, PAM tries remote logins before local logins. This is a serious architectural mistake, which makes it possible for a fault in remote logins to prevent local logins, effectively bricking your box. Let me repeat that. This makes it possible for a fault in remote login logic to prevent local logins and effectively brick the box. This is insane.

There was a talk about 'polyethelene PAM' that you might look up, it was a long time ago and hopefully some of the specific things that he went into have been fixed, but IIRC the author essentially tried to workaround that basic problem and triggered a cascade of more subtle bugginess as PAM fought back. This was an over-architected system that always thought it knew best and introduced the opportunities for failures both spectacular and subtle as a result.

Authentication, anything critical to the system really, needs to be simple and correct, not complicated and clever. This is the same fundamental objection I have to the systemd/corebuntu stuff. I dont like to tear out simple, correct, robust logic and replace it with a clever rube goldberg device. This is a recipe for lots of trouble, even if it's not always easy to predict exactly what shape that trouble will wind up taking.

brianL 07-23-2014 04:36 AM

PAM? Is she su's sister? :scratch: :)
(I've posted this feeble witticism before, and might do again sometime. Sorry.)


All times are GMT -5. The time now is 09:47 PM.