On Wed, 2009-11-18 at 03:49 -0500, Caleb Cushing wrote: > > > > Minimal modification of packages. Allow users to choose for themselves > > instead of doing work for them. I fail to see the security implications > > here for the common user, why would someone want to lock out a user > > without deleting the account except a system admin, who presumably would > > know what to do and would not need a 'simple one-step process'. > > maybe, but it all depends should the admin have to do a full system > security audit? after making these changes I shouldn't have any > problems with kdm, the system is more secure and there are no > disadvantages that I can see. I just can't understand why I had to go > through all of this to start, sure I could make my system even MORE > secure but it's just unnecessary. also one implication in the modified > file I sent is currently failed logins (w/ kdm) don't get logged... > but I don't suppose that the average user reads their failed user > authentication logs, or cares that say a roommate has been trying to > crack there account by hand (because they aren't smart enough to know > how to mount a system drive with a livecd (yes I've had this happen > this is why we hash passwords and make them in the first place not all > users are as smart as us)). The *disadvantage* is that the devs/maintainers have to patch up-stream. This should be kept to a minimum, primarily to reduce their workload, and also because it is ASSUMED that if you use Arch, you're capable of doing the Right Thing (tm) according to your situation, or at least finding out how to. > > I'd > > wager most Arch users simply have 1 account they use all the time, and > > perhaps a guest account for others to use. > > perhaps so... but as I've said this doesn't negatively impact them. > the size is negligible and the benefits are helping people who are > ignorant of weak pam settings and may not have checked that an account > they thought was disabled actually was. I'm just happy I checked. As above, its not about the negative impact on the general user-base, but simply the fact that Arch is not Ubuntu or Fedora with dozens and hundreds of devs/maintainers, some of whom are full-time. I believe the Arch wiki talks about giving users *control* and *responsibility* over their systems, and at least part of this is due to the fact that it does not make sense for a dev to be putting in AND maintaining patches such as these if its not a big security hole or something which affects a wide userbase. > > This isn't a security hole, and it isn't the responsibility of Arch devs > > to make decisions for the users except in extreme cases. > > > how is this making decisions for users? arch makes decisions for users > all the time. I'd guess that arch has done SOME setup of pam. It's a > distributions job to make relatively sane and secure defaults. a > distibution shouldn't do insane security, like require usb key auth > (unless that kind of security is distro focus). but if there's no > serious performance impact, and no visible user impact, then why > should a distro implement a secure as possible by default setup? Arch isn't your normal distro. And the core assumption that Arch is responsible for your security is partly false. Yes, big problems have to be faced up to. This isn't one of them.
