Re: [crux-devel] meeting notes & next IRC Meeting
On Mon, 29 May 2006 22:18:20 +0200 Mark Rosenstand <mark@borkware.net> wrote:
-------- Forwarded Message -------- From: Johannes Winkelmann <jw@smts.ch> To: crux-devel@lists.crux.nu Subject: [crux-devel] meeting notes & next IRC Meeting Date: Mon, 29 May 2006 09:16:22 +0200
Hi there,
This is a quick notification to let you know about last friday's meeting, and the upcoming one next wednesday (may 31).
Last friday, we mainly discussed issues around 2.3 and random ideas that came up. Here's a brief summary:
- We'll try to push out 2.3 later this year (Q3/Q4) if possible; it'll include at least the following: - Xorg 7.1 - gcc 4.1.x (note that I'd consider it safe to update gcc via ports during the 2.2 cycle, but that's up for discussion) - glibc 2.4
- Extend setup to handle modular X; one idea which was discussed and considered viable was to do grouping, such that one could first select the core group, the xorg group, and the [name to be found; remaining packages from opt] group
- The idea of dependency handling during 'setup' was brought up, but not discussed in detail yet [personal remark: easier with dependencies in packages] - some devs would like to see easier update procedures, to avoid the CD boot/reboot for updates; not discussed in detail either, though interesting and definitely wanted by many
- We'll review Matt's ISO scripts and merge them into the svn Makefile where appropriate
- Cleaning up the package selection; we want to do that, but didn't decide which packages should go or be replaced
- We'll start the public wiki section as soon as we find a volunteer to look after it (i.e. check the entries from time to time for spam or unwanted stuff).
- we'll set up ck4up on crux.nu to check core ports; jue has kindly provided a special version and a configuration file
In addition, danm proposed the following three feature additions, noting that we claim to utilize on using recent libs and tools:
1. move /etc/rc.d/net to iproute2 The consensus here was that we'll move /etc/rc.d/net to iproute2 for 2.3 but keep shipping net-tools
If iproute2 is smaller/simpler/better in some way to ifconfig, then I'm all for it.
2. use PAM This has to be investigated, it's a tough balance between features and simplicity; integrating CRUX into certain infrastructures can be rather hard without PAM, and the transition seems painful. We need to evaluate the impact of this before deciding
I think we're better off without it, CRUX is, after all, a distribution following the KISS way of life, so complexity like this seems wrong. I would probably end up modifying half of core/opt/contrib to kill PAM from my system and I think others who enjoy the simplicity of CRUX would probably get annoyed by PAM. I vote that PAM stays out of CRUX.
3. install info pages This wasn't all that controversal as it might seem :-). In general, we agree that info pages contain important information at times, and we have to admit that several users would like to have them; we also agree that some consider them junk :-). We to slightly change our position on this, such that: - we move texinfo to core and require maintainers to have it installed (since some packages conditionally install the info pages only if texinfo is there) - we require that packages install their info pages - we extend pkgadd to support hooks such as: INSTALL ^usr/info/.*$ NO
Whether 'NO' or 'YES' will be the default here is to be decided, but taking this route makes our packages more flexible without sacrificing a lot. As a personal remark, the same rule should IMO be used for desktop files and icons, i.e. install in general, allow rejection via pkgadd.conf. If/When we do this, we'll have to (re-)define 'junk' though; some might say that this way, we could just as well install /usr/share/doc and reject it by default, or even translations. Prepare some arguments :-)
I'm all for this, since some programs (e.g gcc) only document some really good information in their info pages and I'd like to have that on hand if I wanted to read over it.
As a result, we've started a todo list in the wiki: http://crux.nu/Main/ToDo
The next IRC meeting will be this coming wednesday, same time (20 CEST). I suggest the following agenda:
- Quickly discuss open points from last meeting - discuss 'ToDo', and responsibilities in general - future of pkgutils (especially WRT the INSTALL feature mentioned above)
Please post further discussion points in this thread. We'll do futher meetings as needed.
Thanks for your attention, Johannes
-- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
On Monday 29 May 2006 22:36, Brett Goulder wrote:
1. move /etc/rc.d/net to iproute2 The consensus here was that we'll move /etc/rc.d/net to iproute2 for 2.3 but keep shipping net-tools
If iproute2 is smaller/simpler/better in some way to ifconfig, then I'm all for it.
It's not smaller and it's not simpler [1]. It is the only tool that takes advantage of recent kernel network features [2].
2. use PAM This has to be investigated, it's a tough balance between features and simplicity; integrating CRUX into certain infrastructures can be rather hard without PAM, and the transition seems painful. We need to evaluate the impact of this before deciding
I think we're better off without it, CRUX is, after all, a distribution following the KISS way of life, so complexity like this seems wrong. I would probably end up modifying half of core/opt/contrib to kill PAM from my system and I think others who enjoy the simplicity of CRUX would probably get annoyed by PAM. I vote that PAM stays out of CRUX.
Why would you get annoyed by PAM? If it is proper configured you won't even notice the difference nor you need to touch it. Only to make that clear: PAM is the de facto standard (ALL major Linux distributions ship it). New directory services/infrastructures requiring authentication utilize PAM (e.g. kerberos, ldap). I don't like this egoistic thinking: "I don't need it -> leave it out!". It's a pain in the ass to configure PAM if it is not pre-installed. People depending on PAM have to modify numerous ports only to get it running ('cause it doesn't work out-of-the-box). Later then, they need to keep an eye of every particular port they have modified (port updates, security flaws etc.).
[..] I would probably end up modifying half of core/opt/contrib to kill PAM from my system [..]
Just don't touch it. getspent(3) works with and without PAM - you're not forced to access your system's /etc/shadow file through pam(_unix).
I think we're better off without it, CRUX is, after all, a distribution following the KISS way of life, so complexity like this seems wrong.
CRUX users need to configure their kernels themself, configure their system without GUI editors, have to compile applications themself and you're telling me that PAM is too 'complex'? Or did you mean the CRUX user base is too lazy to read documentation[3]? Let me quote some words I found on CRUX's main page "[..] targeted at experienced Linux users", "The secondary focus is utilization of new Linux features and recent tools and libraries". bye, danm PS: I kindly ask you to reconfigure your mail client to NOT include the email addresses then answering. In Sylpheed go to Configuration -> Common Preferences -> Tab: Compose -> Tab: Format Please replace the %f symbol to %N in the "Reply format" text box and remove From:, To: and CC: completely in the "Forward format" text box. Thanks. [1] http://crux.danm.de/files/x86/iproute2/net.rc [2] http://linux-net.osdl.org/index.php/Iproute2 [3] http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/ -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
On Wed, May 31, 2006 at 12:40:01AM +0200, Daniel Mueller wrote:
is the de facto standard (ALL major Linux distributions ship it). New
Oh. You are very very wrong. Slackware do not use PAM by default, afaik. It's on 11 place according to distrowatch. ;-) What PAM gives to me? To you? Why would you use it? http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-3.html : --- "That is, you can authenticate from anything as naive as simple trust (pam_permit) to something as paranoid as a combination of a retinal scan, a voice print and a one-time password! .... To illustrate the flexibility you face, consider the following situation: a system administrator (parent) wishes to improve the mathematical ability of her users (children). She can configure their favorite ``Shoot 'em up game'' (PAM-aware of course) to authenticate them" --- Unfortunately it's not impressive, as I don't have retinal scaner, and I don't want to play ``shoot 'em up'' game on login phase. ;-) It's not clear to me why I'm, as crux user, have to use PAM. May be I would love it if someone explain to me what it gives. Thanks, -- Anton (irc: bd2)
On Wed, 31 May 2006 00:40:01 +0200 Daniel Mueller wrote:
On Monday 29 May 2006 22:36, Brett Goulder wrote:
1. move /etc/rc.d/net to iproute2 The consensus here was that we'll move /etc/rc.d/net to iproute2 for 2.3 but keep shipping net-tools
If iproute2 is smaller/simpler/better in some way to ifconfig, then I'm all for it.
It's not smaller and it's not simpler [1]. It is the only tool that takes advantage of recent kernel network features [2].
2. use PAM This has to be investigated, it's a tough balance between features and simplicity; integrating CRUX into certain infrastructures can be rather hard without PAM, and the transition seems painful. We need to evaluate the impact of this before deciding
I think we're better off without it, CRUX is, after all, a distribution following the KISS way of life, so complexity like this seems wrong. I would probably end up modifying half of core/opt/contrib to kill PAM from my system and I think others who enjoy the simplicity of CRUX would probably get annoyed by PAM. I vote that PAM stays out of CRUX.
Why would you get annoyed by PAM? If it is proper configured you won't even notice the difference nor you need to touch it. Only to make that clear: PAM is the de facto standard (ALL major Linux distributions ship it). New directory services/infrastructures requiring authentication utilize PAM (e.g. kerberos, ldap). I don't like this egoistic thinking: "I don't need it -> leave it out!". It's a pain in the ass to configure PAM if it is not pre-installed. People depending on PAM have to modify numerous ports only to get it running ('cause it doesn't work out-of-the-box). Later then, they need to keep an eye of every particular port they have modified (port updates, security flaws etc.).
It's a complex piece of code prone to problems and tends to introduce so much excess that I do NOT use, I figure that most people who just need a simple log in system as I do would also get annoyed. Most applications can optionally disable PAM support with something as simple as a ./configure switch, others can't, but for the most part PAM support is entirely optional in 90% of applications on UNIX-Like/Linux.
[..] I would probably end up modifying half of core/opt/contrib to kill PAM from my system [..]
Just don't touch it. getspent(3) works with and without PAM - you're not forced to access your system's /etc/shadow file through pam(_unix).
I'm a minimalist, I try to keep things as simple as possible, and I wouldn't be able to deal with having excess such as PAM on my system, as it contradicts my commitment to minimalist (one of the major reasons I choose CRUX and stuck with it was that it was minimalist out of the box).
I think we're better off without it, CRUX is, after all, a distribution following the KISS way of life, so complexity like this seems wrong.
CRUX users need to configure their kernels themself, configure their system without GUI editors, have to compile applications themself and you're telling me that PAM is too 'complex'? Or did you mean the CRUX user base is too lazy to read documentation[3]? Let me quote some words I found on CRUX's main page "[..] targeted at experienced Linux users", "The secondary focus is utilization of new Linux features and recent tools and libraries".
Complexity of implementation and design, PAM is both implementation complex AND design complex, it rolls over the concept of KISS like a steamroller. I never said a thing about configuration of the kernel or using GUI editors, I stated that I think the complexity introduced by PAM is wrong.
bye, danm
PS: I kindly ask you to reconfigure your mail client to NOT include the email addresses then answering. In Sylpheed go to
Configuration -> Common Preferences -> Tab: Compose -> Tab: Format
Please replace the %f symbol to %N in the "Reply format" text box and remove From:, To: and CC: completely in the "Forward format" text box. Thanks.
Done.
[1] http://crux.danm.de/files/x86/iproute2/net.rc [2] http://linux-net.osdl.org/index.php/Iproute2 [3] http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/ -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A _______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
-- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
On Wed, 2006-05-31 at 00:40 +0200, Daniel Mueller wrote:
On Monday 29 May 2006 22:36, Brett Goulder wrote:
1. move /etc/rc.d/net to iproute2 The consensus here was that we'll move /etc/rc.d/net to iproute2 for 2.3 but keep shipping net-tools
If iproute2 is smaller/simpler/better in some way to ifconfig, then I'm all for it.
It's not smaller and it's not simpler [1]. It is the only tool that takes advantage of recent kernel network features [2].
Are you sayng that it's time to re-evaluate the priorities of the CRUX project?
Only to make that clear: PAM is the de facto standard (ALL major Linux distributions ship it).
And RPM is the standard package manager... ;)
I don't like this egoistic thinking: "I don't need it -> leave it out!".
When you talk about small but essential utilities (think jfsutils, e2fsprogs, etc.) that's true. But when you think about big, complex systems that affect large parts of the distro, this is what makes the difference between a focused project like CRUX and the "this could be useful in theory, and will make our feature list longer - it's in!" type of distros.
It's a pain in the ass to configure PAM if it is not pre-installed. People depending on PAM have to modify numerous ports only to get it running ('cause it doesn't work out-of-the-box). Later then, they need to keep an eye of every particular port they have modified (port updates, security flaws etc.).
Isn't this how all "maintainer disagreements" work? By including a svn.driver and making it the default, people could just edit the ports and (non-conflicting) changes get automatically merged. This is what I do, and it isn't that much slower than rsync.
Let me quote some words I found on CRUX's main page "[..] targeted at experienced Linux users", "The secondary focus is utilization of new Linux features and recent tools and libraries".
You accidently forgot this one: "The primary focus of this distribution is keep it simple" That's not to say that PAM should be forever left out, but like Anton said, it would be nice to see a list of what the added complexity gives us.
I hope Anton and Brett will read this mail as well - I'll try to answer all open questions within this mail. On Wednesday 31 May 2006 08:07, Mark Rosenstand wrote:
Are you sayng that it's time to re-evaluate the priorities of the CRUX project?
Indeed.
Only to make that clear: PAM is the de facto standard (ALL major Linux distributions ship it).
And RPM is the standard package manager... ;)
You are comparing apples and oranges. There are lots of alternatives for RPM (dpkg, pkgutils, ..). If you want your linux box joining a corporate network with centralized password management (ldap, samba/ad or kerberos) -> PAM is your (only) choice (AND YES: I know about "NIS" which works fully PAM-less and is insecure as hell AND I know various commercial products I don't want to talk about 'cause they just suck).
[..] svn.driver and making it the default, people could just edit the ports and (non-conflicting) changes get automatically merged. This is what I do, and it isn't that much slower than rsync.
Hmm, I think you've missed my point here. I don't want a separated ports collection. We are not talking about one or two 'conflicting' ports. PAM is .. comprehensive (in words: all programs, libraries and tools dealing with passwords/authentication). However, in most cases it's just an additional configure switch and sometimes a (pre-configured!) service file placed in /etc/pam.d/. Joe User won't even notice that he's using PAM.
Let me quote some words I found on CRUX's main page "[..] targeted at experienced Linux users", "The secondary focus is utilization of new Linux features and recent tools and libraries".
You accidently forgot this one: "The primary focus of this distribution is keep it simple"
I knowingly left it out. "KISS" Really, I start to hate these four letters. It's the ultimate power abbreviation to choke new ideas and concepts. On Wednesday 31 May 2006 01:20, Anton wrote:
is the de facto standard (ALL major Linux distributions ship it). Oh. You are very very wrong. Slackware do not use PAM by default, afaik. It's on 11 place according to distrowatch.
Ieeeeek! Shame on me! -> ALL - 1 major Linux distr....
Unfortunately it's not impressive, as I don't have retinal scaner, and I don't want to play ``shoot 'em up'' game on login phase. ;-) It's not clear to me why I'm, as crux user, have to use PAM. May be I would love it if someone explain to me what it gives.
Besides of the fact that you will get the possibility to join a corporate network with centralized password management, imagine the following scenario: You've got a brand-new laptop. Your new laptop has the disadvantage of being a popular object of desire for pilferers. The harddisk contains most likely private data (e.g. nude pics of your girlfriend). It's a good idea to encrypt those private files. I hear you saying "Bah, no problem, I don't need PAM for this". Okay; you would probably create some container files in your home directory and mount them if needed. Now let's imagine the thief is a smart one and he's looking for tracks in your home directory (.bash_history, .kde/*, .gnome/*, thumbails/* ..). With PAM (pam_mount) it's possible to mount encrypted filesystems during the logon session. That means you could encrypt your whole home directory and mount it automaticlly during login. After you've logged out, PAM will unmount it for you. Of course, you could do the same in some different ways (Many roads lead to Rome).. It was just an example of PAM's numerous capabilities. At the moment I'm enjoying little goodies like xauth forwarding when using su(1). (You may know this message: Xlib: connection to ":0.0" refused by server) On Wednesday 31 May 2006 05:38, Brett Goulder wrote:
It's a complex piece of code prone to problems and tends to introduce so much excess that I do NOT use, I figure that most people who just need a simple log in system as I do would also get annoyed.
I really don't know how to answer this. Sounds like you just hate PAM and I'm sure I cannot convince you of the opposite. But that's okay. PAM could cause problems, yes. But I still hope we can solve as much as possible at the outset with a proper default configuration.
I'm a minimalist, I try to keep things as simple as possible, and I wouldn't be able to deal with having excess such as PAM on my system, as it contradicts my commitment to minimalist (one of the major reasons I choose CRUX and stuck with it was that it was minimalist out of the box).
Is CRUX a minimalist Linux distribution? I started with CRUX 0.7 or 0.8. At that time Per spoke of "lightweight", "i686-optimized" and "A distribution without useless or obsolete files" (so called junk files: README, INSTALL, bla). Did I misunderstand his primary goal from the beginning?
Complexity of implementation and design, PAM is both implementation complex AND design complex, it rolls over the concept of KISS like a steamroller.
It's not _that_ hard. The pam(8) manpage gives you a short overview with just 96 lines of text. It also says: "From the point of view of the system administrator, for whom this manual is provided, it is not of primary importance to understand the internal behavior of the Linux-PAM library." By the way, a lot of pam modules provide their own manpage (e.g. man 8 pam_cracklib). Yesterday I summarized PAM enabled core ports in a tarball (cracklib, linux-pam, openssh, shadow)[1]. I'd like to thank you guys for your answers :-). They gave me an impression of what CRUX users think about my (revolutionary?) ideas and what I'll do in future. bye, danm [1] http://crux.danm.de/files/x86/pam/pam-ports.tar.gz -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
Daniel Mueller [2006-05-31 20:52]:
I'd like to thank you guys for your answers :-). They gave me an impression of what CRUX users think about my (revolutionary?) ideas and what I'll do in future.
Well, don't forget about the silent masses, who don't have such strong opinions on PAM one way or the other :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Wednesday 31 May 2006 1:03, Tilman Sauerbeck wrote:
Daniel Mueller [2006-05-31 20:52]:
I'd like to thank you guys for your answers :-). They gave me an impression of what CRUX users think about my (revolutionary?) ideas and what I'll do in future.
Well, don't forget about the silent masses, who don't have such strong opinions on PAM one way or the other :)
:-) I'd like to second the silent masses' motion, although by sending this email I might be forfeiting my claim of being part of the "silent masses". On Wednesday 31 May 2006 12:52, Daniel Mueller wrote:
Of course, you could do the same in some different ways (Many roads lead to Rome).. It was just an example of PAM's numerous capabilities. At the moment I'm enjoying little goodies like xauth forwarding when using su(1). (You may know this message: Xlib: connection to ":0.0" refused by server)
I've always gotten around that by using sudo -s, though I agree that it's a neat goody to have.
By the way, a lot of pam modules provide their own manpage (e.g. man 8 pam_cracklib).
Cracklib is another one of these goodies, I think. Isn't it cracklib which lets a user know how strong his/her new password is? From an administrative perspective, isn't it good to know that one can hold one's users responsible for choosing passwords of a certain strength? Also, isn't it possible to enforce the use of strong passwords with PAM? Security comes down to how easy it is to break the weakest link, and isn't there compelling evidence to show that as good as a sysadmin is, his users can still mess it all up. Weak user password + dictionary attack + a local exploit, for example...
On Wednesday 31 May 2006 01:20, Anton wrote:
is the de facto standard (ALL major Linux distributions ship it).
Oh. You are very very wrong. Slackware do not use PAM by default, afaik. It's on 11 place according to distrowatch.
Ieeeeek! Shame on me! -> ALL - 1 major Linux distr....
But, on the other hand, both FreeBSD (Han: Does OpenBSD use PAM of any kind?), and NetBSD use PAM, and (in my opinion) CRUX is *the* most BSD-like of all Linux distributions. Perhaps we can one-up Slackware on it's claim to "most BSD-like Linux distro" by becoming more Free/OpenBSD like... ;-) The addition of PAM != acceleration of our distribution into some sort of unstable Fedora, Mandrake, etc. entropy. http://www.onlamp.com/pub/a/bsd/2003/02/20/FreeBSD_Basics.html http://www.freebsd.org/doc/en/articles/pam
On Wednesday 31 May 2006 01:20, Anton wrote:
It's a complex piece of code prone to problems and tends to introduce so much excess that I do NOT use, I figure that most people who just need a simple log in system as I do would also get annoyed.
Anton, could you please cite an example of a problem which would have affected us within the last year? Also, don't things like OpenSSH tend to be updated within only a few hours after a vulnerability is found? Correlatively, aren't CRUX's ports updated very, very soon after such things as an OpenSSH security release? Finally, I think that I read something about running ck4up on the CRUX server, for core ports, so we might soon have an additional safety net for knowing when to patch such things as the infamous PAM + OpenSSH class of vulnerabilities.
Complexity of implementation and design, PAM is both implementation complex AND design complex, it rolls over the concept of KISS like a steamroller.
Does the steamroller leave useful syslog output? Really though, isn't PAM a bit like hotplug/udev, in that while it adds complexity it also adds functionality? AFAICT, CRUX is not a primarily ideological distribution... If we were, then <ahem> we might have prefixed CRUX with a certain recursive three-letter acronym, as has been "discussed" on the old list many, many times. ;-) Finally, if linux-PAM is absolutely terrible, then perhaps we ought to consider something like OpenPAM? Daniel, although OpenPAM sacrifices both "XSSO conformance [though PAM is optional] and Linux-PAM compatibility [because OpenPAM is a minimalistic implementation of PAM]" (http://trac.des.no/openpam) will it solve the authentication problems which you originally addressed? If so, then perhaps OpenPAM is the middle ground between "PAM is the devil!" and "Mephistopheles can be useful". ;-) Ok, I might as well come out and say that I'm not a huge PAM fan, but if PAM is what CRUX needs to become more robust and scalable, and if CRUX can implement PAM well, then mightn't it be worth considering PAM? Cheers, Nick References: http://www.onlamp.com/pub/a/bsd/2003/02/20/FreeBSD_Basics.html http://www.freebsd.org/doc/en/articles/pam http://www.opengroup.org/onlinepubs/008329799 P.S. I'm not particularly looking forward to an upgrade to CRUX + PAM, but I lived through an upgrade which added udev, so perhaps it won't be too painful, so long as we have a really good upgrade guide--which I refuse to write!
On Wed, May 31, 2006 at 05:27:33PM -0600, Nick Steeves wrote:
It's a complex piece of code prone to problems and tends to introduce so much excess that I do NOT use, I figure that most people who just need a simple log in system as I do would also get annoyed.
Anton, could you please cite an example of a problem which would have affected
That wasn't me. :-) Daniel answered multiple mails at one time. -- Anton (irc: bd2)
On Thursday 01 June 2006 01:27, Nick Steeves wrote:
Daniel, although OpenPAM sacrifices both "XSSO conformance [though PAM is optional] and Linux-PAM compatibility [because OpenPAM is a minimalistic implementation of PAM]" (http://trac.des.no/openpam) will it solve the authentication problems which you originally addressed?
I've never heard about 'OpenPAM' before. But I'm sure the work effort needed to integrate it is most likely the same. Using OpenPAM instead of Linux-PAM doesn't feel right anyway. bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
Daniel Mueller wrote:
I've never heard about 'OpenPAM' before. But I'm sure the work effort needed to integrate it is most likely the same. Using OpenPAM instead of Linux-PAM doesn't feel right anyway.
bye, danm
So you've never heard of it, but you're willing to guess it's equally as taxing to implement, and that guess should satisfy the rest of us, and its name alone is enough to dismiss it? Please be more reasonable about this PAM issue. -- Jay Dolan jdolan.dyndns.org A: Because it's annoying to read. Q: Why is top-posting bad? A: Top posting. Q: What's the most annoying thing about usenet?
On Thu, 2006-06-01 at 13:27 -0400, Jay Dolan wrote:
Daniel Mueller wrote:
I've never heard about 'OpenPAM' before. But I'm sure the work effort needed to integrate it is most likely the same. Using OpenPAM instead of Linux-PAM doesn't feel right anyway.
So you've never heard of it, but you're willing to guess it's equally as taxing to implement, and that guess should satisfy the rest of us, and its name alone is enough to dismiss it?
Obviously, just like "I don't like the idea to rewrite pkgutils in C. Isn't C++ the way to go?" (http://crux.nu/Main/PkgutilsIdeas#ntoc28) And also that simplicity shouldn't be a priority as it prevents CRUX from satishfying corporate environments. Who's signing up to write a system installation and administration tool in PyQt?
On Thursday 01 June 2006 19:27, Jay Dolan wrote:
So you've never heard of it, but you're willing to guess it's equally as taxing to implement, and that guess should satisfy the rest of us, and its name alone is enough to dismiss it?
Not only by its name - but in general "yes". I've had a short look at OpenPAM's feature list and its sources. The differences I found were: - less security modules (only pam_unix, pam_permit and pam_deny) and - OpenPAM has its own implementation of su(1).
Please be more reasonable about this PAM issue.
Hmm. I do not longer think that PAM will ever be included in CRUX. Also I had a lot conversations regarding PAM and the result was that nobody really wanted/liked it (I'm a bit tired now). But you're right. I said that the work effort needed to _integrate_ OpenPAM is most likely the same as with Linux-PAM. In both cases all applications with password/authentication code would need an additional configure-script switch (--enable-pam or something). Logon programs like 'kdm', 'gdm' or 'imapd' would need a service file placed in /etc/pam.d/ (e.g. /etc/pam.d/xdm). I don't know whether all programs will interact with OpenPAM since I haven't tested it yet. Maybe some external pam modules[1] won't compile with OpenPAM's library.. I really don't know. bye, danm [1] http://www.kernel.org/pub/linux/libs/pam/modules.html -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
Daniel Mueller wrote:
Not only by its name - but in general "yes". I've had a short look at OpenPAM's feature list and its sources. The differences I found were: - less security modules (only pam_unix, pam_permit and pam_deny) and - OpenPAM has its own implementation of su(1).
Okay - I see now that you did some research before determining it to be inadequate or inappropriate. Your message was so brief..it appeared otherwise.
Hmm. I do not longer think that PAM will ever be included in CRUX. Also I had a lot conversations regarding PAM and the result was that nobody really wanted/liked it (I'm a bit tired now). But you're right.
I don't think that's necessarily true. Personally, I don't have strong feelings either way if, as you said, average users won't have to know or care that it's there. I did not mean to discourage you further, as I know you've met some resistance with your proposal. Johannes has informed me that my tone was harsh in my last message, so if I offended you, I did not intend to and apologize. -- Jay Dolan jdolan.dyndns.org A: Because it's annoying to read. Q: Why is top-posting bad? A: Top posting. Q: What's the most annoying thing about usenet?
On Thursday 01 June 2006 12:08, Daniel Mueller wrote:
I said that the work effort needed to _integrate_ OpenPAM is most likely the same as with Linux-PAM. In both cases all applications with password/authentication code would need an additional configure-script switch (--enable-pam or something). Logon programs like 'kdm', 'gdm' or 'imapd' would need a service file placed in /etc/pam.d/ (e.g. /etc/pam.d/xdm). I don't know whether all programs will interact with OpenPAM since I haven't tested it yet. Maybe some external pam modules[1] won't compile with OpenPAM's library.. I really don't know.
I've read up a little more on OpenPAM. http://lists.freebsd.org/pipermail/freebsd-questions/2004-August/056960.html http://www.cultdeadsheep.org/FreeBSD/docs/Quick_and_dirty_FreeBSD_5_x_and_ns... As far as I can tell, PAM seems to be most useful for ldap authentication. Really, the primary reason I suggested OpenPAM was because it seemed like a more simple (possibly more secure) implementation of PAM--one which would be more palatable to the CRUX community and therefor more likely to garner support because it seems to address several of the arguments against a hulking linux-PAM. Ldap authentication is really cool, and super useful for large networks, but what else can PAM do (oh yeah, kerberos)? IIRC, FreeBSD ships with kerberos support as part of its base installation, and it ships OpenPAM as part of its base, though not linux-PAM, so so long as its base-shipped kerberos is PAM-enabled, it seems to me like OpenPAM works with kerberos. I don't of many the applications which might use (although I read about some sort of older gdm + older OpenPAM + bad logout behaviour because of open file descriptors) it, but it is possible that they can be found on: http://www.freshports.org I think that if linux-pam isn't listed as a dependency, then it's reasonably probable that the package compiles against the FreeBSD-shipped-by-default OpenPAM. As for "all external pam modules"... My guess is definitely no. I've also read that the su program shipped with OpenPAM, as you discovered "- OpenPAM has its own implementation of su(1)" (Mueller) leaves something to be desired. I truly wonder if this alternate "su" is a problem.. I'd be great if Han would join in on this thread, because I seem to remember him having extensive BSD experience. Perhaps he could tell us if pam_mount works with OpenPAM? I'd set up a chroot'ed CRUX installation to test this whole OpenPAM thing, but I'm still pressed for time because of school. Ah, the joys of the "fast" and "cheap" credits of the summer session... Cheers, Nick Resources: [1] http://devmanual.gentoo.org/tasks-reference/pam/index.html [2] http://people.freebsd.org/~des/pam/pam-2002-03.html [3] http://biomark.org.ru/en/software/ [4] http://www.daemon-systems.org/man/pam.3.html [5] http://archives.neohapsis.com/archives/freebsd/2002-09/0080.html [6] http://archives.neohapsis.com/archives/dev/muscle/2005-q3/0082.html Interesting. At the bottom of [4], it says: The OpenPAM library and this manual page were developed for the FreeBSD Project by ThinkSec AS and Network Associates Laboratories, the Security Research Division of Network Associates, Inc.& under DARPA/SPAWAR con- tract N66001-01-C-8035 (``CBOSS''), as part of the DARPA CHATS research program. Could OpenPAM be more secure than linux-PAM for this reason?
On Thursday 01 June 2006 01:27, Nick Steeves wrote:
Daniel, although OpenPAM sacrifices both "XSSO conformance [though PAM is optional] and Linux-PAM compatibility [because OpenPAM is a minimalistic implementation of PAM]" (http://trac.des.no/openpam) will it solve the authentication problems which you originally addressed?
Nick, I don't know - haven't seen it in the wild yet. If OpenPAM works with all external pam modules (pam_krb5, pam_ldap, ..) -> I'd say "yes". bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
Daniel Mueller wrote:
You are comparing apples and oranges. There are lots of alternatives for RPM (dpkg, pkgutils, ..). If you want your linux box joining a corporate network with centralized password management (ldap, samba/ad or kerberos) -> PAM is your (only) choice (AND YES: I know about "NIS" which works fully PAM-less and is insecure as hell AND I know various commercial products I don't want to talk about 'cause they just suck).
But. How many CRUX users are connecting to corporate networks via ldap, samba, or kerberos? Apparently you are..but let's make sure you're not a minority in this instance. I run NIS here for our ~20 node CRUX office with no complaints. I'm not saying that PAM isn't an option. But I was present at CC2K4 when it was unanimously considered bloat for this distro.
Besides of the fact that you will get the possibility to join a corporate network with centralized password management, imagine the following scenario:
You've got a brand-new laptop. Your new laptop has the disadvantage of being a popular object of desire for pilferers. The harddisk contains most likely private data (e.g. nude pics of your girlfriend). It's a good idea to encrypt those private files. I hear you saying "Bah, no problem, I don't need PAM for this". Okay; you would probably create some container files in your home directory and mount them if needed. Now let's imagine the thief is a smart one and he's looking for tracks in your home directory (.bash_history, .kde/*, .gnome/*, thumbails/* ..). With PAM (pam_mount) it's possible to mount encrypted filesystems during the logon session. That means you could encrypt your whole home directory and mount it automaticlly during login. After you've logged out, PAM will unmount it for you.
Wtf? Again, sorry, how does this even relate to, nevermind help, the majority of CRUX users? No offense intended..I'm just.. wow (?) But can I have those nudes? -- Jay Dolan jdolan.dyndns.org A: Because it's annoying to read. Q: Why is top-posting bad? A: Top posting. Q: What's the most annoying thing about usenet?
Jay Dolan [2006-05-31 15:16]:
Besides of the fact that you will get the possibility to join a corporate network with centralized password management, imagine the following scenario:
You've got a brand-new laptop. Your new laptop has the disadvantage of being a popular object of desire for pilferers. The harddisk contains most likely private data (e.g. nude pics of your girlfriend). It's a good idea to encrypt those private files. I hear you saying "Bah, no problem, I don't need PAM for this". Okay; you would probably create some container files in your home directory and mount them if needed. Now let's imagine the thief is a smart one and he's looking for tracks in your home directory (.bash_history, .kde/*, .gnome/*, thumbails/* ..). With PAM (pam_mount) it's possible to mount encrypted filesystems during the logon session. That means you could encrypt your whole home directory and mount it automaticlly during login. After you've logged out, PAM will unmount it for you.
Wtf? Again, sorry, how does this even relate to, nevermind help, the majority of CRUX users? No offense intended..I'm just.. wow (?)
Are you saying the majority of CRUX users doesn't have a need for easy encryption of their data? No offense intended, but wtf? ;) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Wed, 31 May 2006 20:52:50 +0200 Daniel Mueller wrote:
I hope Anton and Brett will read this mail as well - I'll try to answer all open questions within this mail.
On Wednesday 31 May 2006 08:07, Mark Rosenstand wrote:
Are you sayng that it's time to re-evaluate the priorities of the CRUX project?
Indeed.
Only to make that clear: PAM is the de facto standard (ALL major Linux distributions ship it).
And RPM is the standard package manager... ;)
You are comparing apples and oranges. There are lots of alternatives for RPM (dpkg, pkgutils, ..). If you want your linux box joining a corporate network with centralized password management (ldap, samba/ad or kerberos) -> PAM is your (only) choice (AND YES: I know about "NIS" which works fully PAM-less and is insecure as hell AND I know various commercial products I don't want to talk about 'cause they just suck).
[..] svn.driver and making it the default, people could just edit the ports and (non-conflicting) changes get automatically merged. This is what I do, and it isn't that much slower than rsync.
Hmm, I think you've missed my point here. I don't want a separated ports collection. We are not talking about one or two 'conflicting' ports. PAM is .. comprehensive (in words: all programs, libraries and tools dealing with passwords/authentication). However, in most cases it's just an additional configure switch and sometimes a (pre-configured!) service file placed in /etc/pam.d/. Joe User won't even notice that he's using PAM.
Let me quote some words I found on CRUX's main page "[..] targeted at experienced Linux users", "The secondary focus is utilization of new Linux features and recent tools and libraries".
You accidently forgot this one: "The primary focus of this distribution is keep it simple"
I knowingly left it out. "KISS" Really, I start to hate these four letters. It's the ultimate power abbreviation to choke new ideas and concepts.
I don't try to choke new concepts at ALL, but CRUX IS a KISS distro and we shouldn't start violating it's primary concepts out-of-the-fscking-blue.
On Wednesday 31 May 2006 01:20, Anton wrote:
is the de facto standard (ALL major Linux distributions ship it). Oh. You are very very wrong. Slackware do not use PAM by default, afaik. It's on 11 place according to distrowatch.
Ieeeeek! Shame on me! -> ALL - 1 major Linux distr....
Unfortunately it's not impressive, as I don't have retinal scaner, and I don't want to play ``shoot 'em up'' game on login phase. ;-) It's not clear to me why I'm, as crux user, have to use PAM. May be I would love it if someone explain to me what it gives.
Besides of the fact that you will get the possibility to join a corporate network with centralized password management, imagine the following scenario:
You've got a brand-new laptop. Your new laptop has the disadvantage of being a popular object of desire for pilferers. The harddisk contains most likely private data (e.g. nude pics of your girlfriend). It's a good idea to encrypt those private files. I hear you saying "Bah, no problem, I don't need PAM for this". Okay; you would probably create some container files in your home directory and mount them if needed. Now let's imagine the thief is a smart one and he's looking for tracks in your home directory (.bash_history, .kde/*, .gnome/*, thumbails/* ..). With PAM (pam_mount) it's possible to mount encrypted filesystems during the logon session. That means you could encrypt your whole home directory and mount it automaticlly during login. After you've logged out, PAM will unmount it for you.
Of course, you could do the same in some different ways (Many roads lead to Rome).. It was just an example of PAM's numerous capabilities. At the moment I'm enjoying little goodies like xauth forwarding when using su(1). (You may know this message: Xlib: connection to ":0.0" refused by server)
I have gnupg and that tends to be decent enough for 99% of my work, the other things I clean manually every now and then. Plus, by the time a hacker has gained access enough to remove my drive or read my data, basically anything is screwed right then and there, I just use gpg on stuff I prefer to keep private. Encryption does screw him over in the terms that if he just removes my drive and mounts it, he'll get nothing of worth, but seriously, he's more likely to get through my password and upload the data somewhere. This only becomes a serious problem when you start to talk about laptops, but if you leave your laptop unattended, your asking for whatever you get.
On Wednesday 31 May 2006 05:38, Brett Goulder wrote:
It's a complex piece of code prone to problems and tends to introduce so much excess that I do NOT use, I figure that most people who just need a simple log in system as I do would also get annoyed.
I really don't know how to answer this. Sounds like you just hate PAM and I'm sure I cannot convince you of the opposite. But that's okay.
PAM could cause problems, yes. But I still hope we can solve as much as possible at the outset with a proper default configuration.
I'm a minimalist, I try to keep things as simple as possible, and I wouldn't be able to deal with having excess such as PAM on my system, as it contradicts my commitment to minimalist (one of the major reasons I choose CRUX and stuck with it was that it was minimalist out of the box).
Is CRUX a minimalist Linux distribution? I started with CRUX 0.7 or 0.8. At that time Per spoke of "lightweight", "i686-optimized" and "A distribution without useless or obsolete files" (so called junk files: README, INSTALL, bla). Did I misunderstand his primary goal from the beginning?
Complexity of implementation and design, PAM is both implementation complex AND design complex, it rolls over the concept of KISS like a steamroller.
It's not _that_ hard. The pam(8) manpage gives you a short overview with just 96 lines of text. It also says:
"From the point of view of the system administrator, for whom this manual is provided, it is not of primary importance to understand the internal behavior of the Linux-PAM library."
By the way, a lot of pam modules provide their own manpage (e.g. man 8 pam_cracklib).
Yesterday I summarized PAM enabled core ports in a tarball (cracklib, linux-pam, openssh, shadow)[1].
From my point of view, I must know what is going on behind-the-scenes, I do not like things happening behind my back and PAM introduces a whole lot of that. Complex systems like PAM introduce overhead in terms of knowing your security system, you need to know every-single-part of PAM too possibly know your own security system and that is just fscking crazy, on top of that, I can cite at least one instance where PAM caused an otherwise avoidable problem (it was a vulnerability in openssh).
I'd like to thank you guys for your answers :-). They gave me an impression of what CRUX users think about my (revolutionary?) ideas and what I'll do in future.
bye, danm
[1] http://crux.danm.de/files/x86/pam/pam-ports.tar.gz -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A _______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
-- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
Just a quick note here, the signature to the former message got seriously fudged up. -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
On Wed, May 31, 2006 at 08:52:50PM +0200, Daniel Mueller wrote:
Besides of the fact that you will get the possibility to join a corporate network with centralized password management, imagine the following scenario:
You've got a brand-new laptop. Your new laptop has the disadvantage of being a popular object of desire for pilferers. The harddisk contains most likely private data (e.g. nude pics of your girlfriend). It's a good idea to encrypt those private files. I hear you saying "Bah, no problem, I don't need PAM for this". Okay; you would probably create some container files in your home directory and mount them if needed. Now let's imagine the thief is a smart one and he's looking for tracks in your home directory (.bash_history, .kde/*, .gnome/*, thumbails/* ..). With PAM (pam_mount) it's possible to mount encrypted filesystems during the logon session. That means you could encrypt your whole home directory and mount it automaticlly during login. After you've logged out, PAM will unmount it for you.
Of course, you could do the same in some different ways (Many roads lead to Rome).. It was just an example of PAM's numerous capabilities. At the moment I'm enjoying little goodies like xauth forwarding when using su(1). (You may know this message: Xlib: connection to ":0.0" refused by server)
Daniel, thank you for detailed explanation. That is impressive. Though I do not plan to use these features myself in near future. Anyway, there is the way to make happy both sides, those who like PAM and those who don't. It is... Subversion! Yeah, really. Why not make svn as default ports driver? Everybody can make their changes as they like. There may be some user contributed make-crux-PAMless.patch for every release. Changes do not disappear when you are updating ports. I use svn driver a long time, without any problems. And I have upgraded crux-2.1 to crux-2.2 using `svn diff core/ > ~/core.diff' and `svn diff opt/ > ~/opt.diff'. That was piece of cake, and I get back configure flags that *I* like, just by patching core and opt. Though, if svn driver will be default, then `ports -u' action must also check for conflicts and warn about them (that is easy to implement using `svn status | grep'). IMHO, that resolves all contests about default configure flags, without any harm. Good luck, -- Anton (irc: bd2) p.s. Please, announce here when you are planning to discuss ideas about pkgtools rewrite, attributes, e.t.c. I have some thoughts about it. (Shortly: I do not like idea of attributes in /var/lib/pkg/db, but I do like idea[1] that Oleksiy Khilkevich proposed, i.e. put whole Pkgfile and related files into binary package. Simple, without complexity. Everybody happy.) Just my 2 cents. [1] http://lists.crux.nu/pipermail/crux-devel/2006-April/001672.html
On Wed, May 31, 2006 at 08:52:50PM +0200, Daniel Mueller wrote: [...] Daniel, thank you for detailed explanation. That is impressive. Though I do not plan to use these features myself in near future.
Anyway, there is the way to make happy both sides, those who like PAM and those who don't. It is... Subversion! Yeah, really. Why not make svn as default ports driver? Because it's introducing a large number of new problems, and solves a
Hi Anton, On Thu, Jun 01, 2006 at 03:23:50 +0400, Anton wrote: problem only a subset of users have.
p.s. Please, announce here when you are planning to discuss ideas about pkgtools rewrite, We have announced this, in this very thread (that's why it has this subject BTW :-)). You can read it here (scroll down to "The next IRC meeting..."): http://lists.crux.nu/pipermail/crux-devel/2006-May/001690.html
The discussion was yesterday, and we decided to go for an attribute based approach. Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Thu, Jun 01, 2006 at 08:40:38AM +0200, Johannes Winkelmann wrote:
and we decided to go for an attribute based approach.
Crap! Please don't tell me that you even decided to uncomment "Depends on:", "Maintainer:",... lines. Do you? -- Anton (irc: bd2)
On Thu, Jun 01, 2006 at 15:31:22 +0400, Anton wrote:
On Thu, Jun 01, 2006 at 08:40:38AM +0200, Johannes Winkelmann wrote:
and we decided to go for an attribute based approach.
Crap! Please don't tell me that you even decided to uncomment "Depends on:", "Maintainer:",... lines. Do you?
We "even" decided to uncomment those fields. Basically we'll get rid of all those hacks and finally get clean formats for ports (as they were before CLC pushed the comment headers) and installed packages (no more hacks for locking, aliases etc.). Or to quote you from your previous mail: "Simple, without complexity. Everybody happy". Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Thu, Jun 01, 2006 at 01:37:13PM +0200, Johannes Winkelmann wrote:
On Thu, Jun 01, 2006 at 15:31:22 +0400, Anton wrote:
On Thu, Jun 01, 2006 at 08:40:38AM +0200, Johannes Winkelmann wrote:
and we decided to go for an attribute based approach.
Crap! Please don't tell me that you even decided to uncomment "Depends on:", "Maintainer:",... lines. Do you?
We "even" decided to uncomment those fields. Basically we'll get rid of all those hacks and finally get clean formats for ports (as they were before CLC pushed the comment headers) and installed packages (no more hacks for locking, aliases etc.). Or to quote you from your previous mail: "Simple, without complexity. Everybody happy".
Can I suppose that the next step towards removing hacks is introducing versioned dependencies and USE flags? No offence, they ARE useful in some environments. -- Anton (irc: bd2)
Hi, On Thu, Jun 01, 2006 at 15:59:35 +0400, Anton wrote:
On Thu, Jun 01, 2006 at 01:37:13PM +0200, Johannes Winkelmann wrote: [...]
We "even" decided to uncomment those fields. Basically we'll get rid of all those hacks and finally get clean formats for ports (as they were before CLC pushed the comment headers) and installed packages (no more hacks for locking, aliases etc.). Or to quote you from your previous mail: "Simple, without complexity. Everybody happy".
Can I suppose that the next step towards removing hacks is introducing versioned dependencies and USE flags?
Let me quote Adam Jackson [1] here: "It's hard to express just how misguided you seem to be in mere words. So instead, here's a picture of a cute baby fox: http://people.freedesktop.org/~ajax/fennec-fox.jpg HTH. HAND." Johannes References: 1. http://article.gmane.org/gmane.comp.freedesktop.xorg/7728 -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Thu, Jun 01, 2006 at 02:12:06PM +0200, Johannes Winkelmann wrote:
Let me quote Adam Jackson [1] here:
"It's hard to express just how misguided you seem to be in mere words. So instead, here's a picture of a cute baby fox:
http://people.freedesktop.org/~ajax/fennec-fox.jpg
HTH. HAND."
Johannes
Thank you. Your quote explains a lot, particularly the attitude. But I'm not PhD student, and I don't plan to argue with all of you about yours chooses. No problem, nobody forces me to upgrade to new version. I'm pretty happy with "crux in early development stage", and I don't want to go forward the way you are going. Best wishes, -- Anton (irc: bd2)
can someone remove me from this mailing list As I do not know anyone and don't even use IRC thanks -----Original Message----- From: crux-devel-bounces@lists.crux.nu [mailto:crux-devel-bounces@lists.crux.nu] On Behalf Of Daniel Mueller Sent: May 31, 2006 PM 12:53 To: crux-devel@lists.crux.nu Subject: Re: [crux-devel] meeting notes & next IRC Meeting I hope Anton and Brett will read this mail as well - I'll try to answer all open questions within this mail. On Wednesday 31 May 2006 08:07, Mark Rosenstand wrote:
Are you sayng that it's time to re-evaluate the priorities of the CRUX project?
Indeed.
Only to make that clear: PAM is the de facto standard (ALL major Linux distributions ship it).
And RPM is the standard package manager... ;)
You are comparing apples and oranges. There are lots of alternatives for RPM (dpkg, pkgutils, ..). If you want your linux box joining a corporate network with centralized password management (ldap, samba/ad or kerberos) -> PAM is your (only) choice (AND YES: I know about "NIS" which works fully PAM-less and is insecure as hell AND I know various commercial products I don't want to talk about 'cause they just suck).
[..] svn.driver and making it the default, people could just edit the ports and (non-conflicting) changes get automatically merged. This is what I do, and it isn't that much slower than rsync.
Hmm, I think you've missed my point here. I don't want a separated ports collection. We are not talking about one or two 'conflicting' ports. PAM is .. comprehensive (in words: all programs, libraries and tools dealing with passwords/authentication). However, in most cases it's just an additional configure switch and sometimes a (pre-configured!) service file placed in /etc/pam.d/. Joe User won't even notice that he's using PAM.
Let me quote some words I found on CRUX's main page "[..] targeted at experienced Linux users", "The secondary focus is utilization of new Linux features and recent tools and libraries".
You accidently forgot this one: "The primary focus of this distribution is keep it simple"
I knowingly left it out. "KISS" Really, I start to hate these four letters. It's the ultimate power abbreviation to choke new ideas and concepts. On Wednesday 31 May 2006 01:20, Anton wrote:
is the de facto standard (ALL major Linux distributions ship it). Oh. You are very very wrong. Slackware do not use PAM by default, afaik. It's on 11 place according to distrowatch.
Ieeeeek! Shame on me! -> ALL - 1 major Linux distr....
Unfortunately it's not impressive, as I don't have retinal scaner, and I don't want to play ``shoot 'em up'' game on login phase. ;-) It's not clear to me why I'm, as crux user, have to use PAM. May be I would love it if someone explain to me what it gives.
Besides of the fact that you will get the possibility to join a corporate network with centralized password management, imagine the following scenario: You've got a brand-new laptop. Your new laptop has the disadvantage of being a popular object of desire for pilferers. The harddisk contains most likely private data (e.g. nude pics of your girlfriend). It's a good idea to encrypt those private files. I hear you saying "Bah, no problem, I don't need PAM for this". Okay; you would probably create some container files in your home directory and mount them if needed. Now let's imagine the thief is a smart one and he's looking for tracks in your home directory (.bash_history, .kde/*, .gnome/*, thumbails/* ..). With PAM (pam_mount) it's possible to mount encrypted filesystems during the logon session. That means you could encrypt your whole home directory and mount it automaticlly during login. After you've logged out, PAM will unmount it for you. Of course, you could do the same in some different ways (Many roads lead to Rome).. It was just an example of PAM's numerous capabilities. At the moment I'm enjoying little goodies like xauth forwarding when using su(1). (You may know this message: Xlib: connection to ":0.0" refused by server) On Wednesday 31 May 2006 05:38, Brett Goulder wrote:
It's a complex piece of code prone to problems and tends to introduce so much excess that I do NOT use, I figure that most people who just need a simple log in system as I do would also get annoyed.
I'm a minimalist, I try to keep things as simple as possible, and I wouldn't be able to deal with having excess such as PAM on my system, as it contradicts my commitment to minimalist (one of the major reasons I choose CRUX and stuck with it was that it was minimalist out of
I really don't know how to answer this. Sounds like you just hate PAM and I'm sure I cannot convince you of the opposite. But that's okay. PAM could cause problems, yes. But I still hope we can solve as much as possible at the outset with a proper default configuration. the box). Is CRUX a minimalist Linux distribution? I started with CRUX 0.7 or 0.8. At that time Per spoke of "lightweight", "i686-optimized" and "A distribution without useless or obsolete files" (so called junk files: README, INSTALL, bla). Did I misunderstand his primary goal from the beginning?
Complexity of implementation and design, PAM is both implementation complex AND design complex, it rolls over the concept of KISS like a steamroller.
It's not _that_ hard. The pam(8) manpage gives you a short overview with just 96 lines of text. It also says: "From the point of view of the system administrator, for whom this manual is provided, it is not of primary importance to understand the internal behavior of the Linux-PAM library." By the way, a lot of pam modules provide their own manpage (e.g. man 8 pam_cracklib). Yesterday I summarized PAM enabled core ports in a tarball (cracklib, linux-pam, openssh, shadow)[1]. I'd like to thank you guys for your answers :-). They gave me an impression of what CRUX users think about my (revolutionary?) ideas and what I'll do in future. bye, danm [1] http://crux.danm.de/files/x86/pam/pam-ports.tar.gz -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A _______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
Hi Nick, On Wed, May 31, 2006 at 22:06:54 -0600, Nick wrote:
can someone remove me from this mailing list As I do not know anyone and don't even use IRC That was my mistake; we recently moved our mailing lists, manually re-subscribed the other developers, and I apparently got one address wrong (nick@ instead of nick.steeves@shaw.ca).
I removed you from the list now, sorry for the inconvenience. Best regards, Johannes Winkelmann -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
participants (9)
-
Anton -
Brett Goulder -
Daniel Mueller -
Jay Dolan -
Johannes Winkelmann -
Mark Rosenstand -
Nick -
Nick Steeves -
Tilman Sauerbeck