i think the main reason is slackware was designed with server stability and security as the main purpose. that's why Pat isn't including too many fancy features, such as automounting.

if you like it, then you can modified your box

Granted, my question was not about automounting, but about HAL. Why is it not part of Slackware?

HAL and udev are supposed to be the standard infrastructure for communication with devices in Linux, and as far as I am able to understand it, the concept is much more flexible and even more secure than what you have without it.

And yes, I can modify my box, of course, but this always means that patches and security fixes have to be applied manually, because you can no long just upgrade a package with a patch provided by the distributor. In fact, *this* causes security problems, as you don't have some expert looking at the details *before* making the patch available. You are all on your own.

On production servers I usually prefer to stick to a stable version and apply patches and hotfixes only, no other upgrades, and only packages from the distributor.

As there is no obvious security problem with HAL, I still would like to know, why it's not active in Slack. Does anyone know?

gargamel

Only the Man himself can truly answer that question, but my guess is that it is because the latest versions of HAL require PAM.

This is a small excerpt from the Slackware-9.1 Changelog.txt:

"Please indulge me for this brief aside (as requests for PAM are on the rise):
If you see a security problem reported which depends on PAM, you can be glad you run Slackware. I think a better name for PAM might be SCAM, for Swiss Cheese Authentication Modules, and have never felt that the small amount of convenience it provides is worth the great loss of system security. We miss out on half a dozen security problems a year by not using PAM, but you can always install it yourself if you feel that you're missing out on the fun. (No, don't do that)
OK, I'm done ranting here. :-)"

So, if HAL continues to require PAM we may never see it packaged as a part of Slackware.

Earlier versions of HAL didn't require PAM, and can easily be made to work with Slackware.

Then there's this little chestnut from the Slackware-current Changelog.txt:

"a/aaa_base-10.2.0-noarch-4.tgz: Chowned all binary directories to root:root.
/media and /svc will not be added at this time, as /mnt (with subdirectory mount points such as /mnt/cdrom and /mnt/tmp) and /var were already perfectly adequate for the purposes for which /media and /svc were proposed.
Polluting the root directory is, IMHO, completely pointless. I suppose in the future that at least compatibility symlinks will need to be considered, though..."

Read into that what you will, but remember that HAL uses the /media directory...

As I see it, the only advantage provided by HAL is the automatic mounting/unmounting of removable media from within the GUI. The udev package shipping with Slackware creates device nodes dynamically, even providing a "by_label" symlink. This trivialises the task of mounting devices manually. Bearing this in mind, the effort required to properly install & configure a current version of HAL far outweighs the benefits it provides, IMHO.

Because automounting needs HAL and this is what people are expected, so i just put it in my post. Sorry if it confuses you

The main reason is that Pat is more concern about the stability and not all the fancy features such as HAL and DBUS and automounting. And maybe the dependency of PAM is perhaps one of the main reason also

Thanks, rkelsen and willysr. The PAM dependency is really a bad thing. Although I have been using SuSE Linux for many years, and still do on some systems, which has PAM, and I couldn't tell that there would have been that many security problems with it. Anyhow, HAL shouldn't depend on PAM.

But let me correct you in one point: Automounting is not all you can do with HAL and udev. Together with Ivman you can program nice scripts like automated directory synchronisation for roaming users. As soon as the mobile device gets connected all modified and new files are transferred to the backup server automagically, without anything the user has to do. Good for guys like me, who tend to be lazy regarding backups...

So, HAL and udev and DBUS and Ivman allow for powerful solutions far beyond a simple automount mechanism. That's why I doubt that Slackware can live without them too long, at least, if it is supposed to remain attractive for desktop users in the future.

I have every sympathy for Pat's point "stability first" attitude, and I think he's totally right to make Slackware a robust server distribution. But HAL and co. are going to be the standard in Linux, at least on desktops.

The same holds for Pat's rejection of /media and other mountpoints that are required by the LSB. On server machines these mountpoints don't make a lot of sense, but on desktops, with lots of different devices of various kinds, it may be useful to have things a bit more organised. Of course, it would have been better, to put subdirectories in /mnt than just in /.
The question now, however, is: What's the difference between having the mountpoints as directories as opposed to having 'compatibility symlinks'? Ok, a directory is a hardlink while a symlink is just that. However, exactly that can prevent some programs from working properly.

Let's see. I definitely trust in Pat's decisions, although I don't understand them all. The result has always been totally convincing and satisfying. I am looking forward to 11.

gargamel

For those who claim that pam is such a security risk, I challenge you to show documented proof
within lets say the last five years of any security advisories issued against it.. Until then, Pat and
all his little lemmings need to shut their pie holes about it. Pat includes X11 which has had many
many many more advisories issued against it than pam ever will but I don't see you all screaming
at Pat to remove that. I'm not saying pam hasn't had "ANY" but I can almost bet that you will find
1 maybe 2 at the max. Which is way less than some of the other stuff that is currently included in
slackware.


P.S. Please don't toss some b.s. reply at this unless you have a few links to back up pams so
called "SECURITY ISSUES"

Ask and ye shall receive...

http://search.securityfocus.com/swse...shlastmodified
http://search.cert.org/query.html?rq...qt=pam&x=0&y=0

Ah, but X adds value. What value would PAM add?

I am not really qualified to answer that, but as far as I understand the idea behind PAM is to have a unified interface to various sources of authentication data. It simplifies application development, when you can program against just one interface, instead of having to program against LDAP other than against MS Exchange (like it or hate it, but it's widely used in enterprises), some enterprise applications from Oracle or SAP and proprietary databases.

If you don't have to identify, authorize and authenticate against various sources, you probably don't need PAM. But your machine is probably not used in a large enterprise, then.

Hope that wasn't all wrong, it's just my basic understanding of what PAM is good for. In my small networks or for simple applications noone needs PAM, but for large scale communication servers, as opposed to what small and medium sized companies need, the concept seems to make sense.

Let me try to guess Pat's reasoning:

Slackware is usually not used as a communication server in large enterprises. It's used as file or web or database server, and the majority of Slackware installations is in smaller sites.
Given that, why take the risk the PAM brings in, when you don't really leverage the benefits?

Or vice versa: If you have to have access to various user repositories, the benefits may justify to use PAM despite the risks. In that case, feel free to install PAM on Slackware, or try some of the other big distros (SuSE, Red Hat, etc.).

As always, it probably depends on what you want to do, and where and how. Pat avoids to include things that aren't going to be used by a significant share of Slackware users. For the same reason Slackware 11 comes without HAL and D-BUS.

gargamel

Besides PAM is a complex security layer from the OS point of view, mentioned network based authentication can be achieved simply even without it by using Network Services Switch module for (Open)LDAP - it's only one library file. Legacy applications needn't to be somehow patched or rewritten and they'll transparently authenticate against remote LDAP databases (besides local passwd/shadow and eventually NIS).
I don't say PAM is a wrong concept but in many cases it's unnecessary complex. F.E. OpenBSD has forsaken it too.

Yes, that's what I was going to say:

Most of the things that can be done with PAM can be done without it, too, and sometimes simpler. That doesn't render the concept of a unified, standardized facade useless. I doubt that the SuSE or Red Hat folks are idiots, to include PAM. I think, their customers just have a demand for it, while most Slackers don't.

This is one of the nicest aspects of Open Source Software and Linux: Freedom of choice.

gargamel