On Fri, Jun 23, 2006 at 02:27:19PM +0200, martin f krafft wrote: > also sprach Derek Martin <code@pizzashack.org> [2006.06.23.1403 +0200]: > > Why should I not make such statements? If Debian is not meeting > > the needs of people who want to use it, why should the Debian > > community not strive to meet those needs? Is the Debian community > > not open to change for the better? > > Sure, for the better. In this case, however, you are the only one > who thinks it's better. Given that, as you say, there are numerous discussions on the net about it, that obviously can't be true. Let me say that my purpose in pursuing this argument is to understand what the reasons are. I'm not attempting to attack you or Debian for their decision. I'm simply trying to understand it. Thusfar, I haven't seen any logical, technical argument that makes that decision make sense... > > I never said you didn't... but can you provide a logical reason > > for discluding support for pam_console? > > Please go through the numerous discussions on the topic in the list > archives. You are not the first to raise this issue, you know? I have already looked at several which you and others have brought up. In every case I've seen so far, I've shown that pam_console is at least no worse than the alternatives, and often actually better. > > Can you find any fault with my analysis? You may not personally > > like pam_console, but it appears to be technically superior to all > > of the debian-supported solutions to the problem of how to provide > > access to system resources to workstation users > > Then I suggest you take a look at the code. If the code is bad, it can be fixed. In principle though, the approach that pam_console takes is technically superior to all of the alternatives. You say that Debian has considered pam_console and rejected it for good reasons. I'm trying to find out what those reasons are... If the sole technical objection to it is bad implementation, why didn't the Debian developers decide to simply fix the code, as they have done with so many other projects? People have pointed me at a few discussions, but in regards to each of those discussions, all of the supported methods are actually worse than pam_console, as I've shown. Did you read my analysis, and seriously consider what I wrote? > > And if you have a logical technical argument against pam_console, > > I'd still like to hear it. > > It's an ugly hack that will cause more problem than it's worth. That's not a technical argument. It's simply an opinion for which you have provided no basis. I've managed hundreds of Red Hat systems which used it, made extensive use of it myself, and have encountered no such problems. It does, however, effectively provide access to peripherals to anyone who logs in on the console. Your assertion appears to be baseless. > > Fine. But, why? I don't think "...because I don't like it" is a very > > reasoned or sensible justification, but that seems to be the only > > justification you are willing to offer. > > You are talking about killing processes and you're asking me why? > > How, for instance, do you want to cope with the situation of letting > a second user log in in KDE or Gnome while the first session is > locked? Just kill the first session? First of all, my intention was that this extension should be an option, not mandantory. PAM allows the modules to have options... If that option is not appropriate for your installation, don't use it. Even without it, pam_console still is more secure (at least in principle, without considering the actual implementation) than the two alternate solutions the Debian community seems to favor. Secondly, how do you propose to allow more than one user to log into the same console simultaneously? The only way this scenario is plausible is if there is more than one physical console attached to the system, or if the same user wants to start multiple sessions in different virtual consoles; this kind of usage is relatively rare, and in either case that particular feature is obviously not for you. But also in that case, someone is going to lose out on using the peripherals, guaranteed. A technical solution which accepts this idea is possible. pam_console could create a lock file, which it would use to determine whether or not someone was already using (or at least had the rights to use) the hardware. If so, it would not reset the permissions upon a second user's login. > > This is starting to seem an awful lot to me like unreasoned > > anti-RedHat prejudice getting in the way of providing solid > > technical solutions to real problems faced by real users every > > day... > > Go ahead and provide the solid solution then. Don't expect others to > do it for you. Isn't that precisely what Linux distributions do? They provide solutions for people so they don't have to do it themselves... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
Attachment:
pgpkzQphMO53k.pgp
Description: PGP signature