Processed: Re: Bug#340375: Subject: kuser destroys all passwords if /etc/shadow isn't present
Processing commands for [EMAIL PROTECTED]: > severity 340375 important Bug#340375: Subject: kuser destroys all passwords if /etc/shadow isn't present Severity set to `important'. > stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340375: Subject: kuser destroys all passwords if /etc/shadow isn't present
severity 340375 important stop Since this bug is largely fixed in Sid, but not so totally resolved that I'd want to attach a "fixed" tag, I think the best course of action is to lower the bug to important, but keep it open. In any case, the bug isn't a regression with respect to what's in Etch at the moment. Cheers, Christopher Martin On Saturday 17 December 2005 14:57, Christopher Martin wrote: > On Tuesday 22 November 2005 20:23, Charles G Montgomery wrote: > > Subject: kuser destroys all passwords if /etc/shadow isn't present > > Package: kuser > > Version: 4:3.4.2-1 > > Severity: grave > > Justification: renders package unusable > > Hello, > > I forwarded the issue upstream, and a check was added for the /etc/shadow > file in the KDE 3.5 branch. The kdeadmin upload that should clear NEW and > be in experimental shortly contains this fix. However, as you noted > yourself, this doesn't completely resolve the issue, since /etc/shadow > could be present but shadow passwords still not in use. > > Upstream seems to be under the astonishing impression that the ability to > disable the use of shadow passwords by clearing "/etc/shadow" from the > shadow file text field in Configure KUser is intuitive and clear to > users. Even the check for /etc/shadow was added reluctantly, and upstream > has stated that he has no intention of adding further checks. > > So what to do? Having /etc/shadow but not using shadow passwords is > probably a pretty rare configuration. We could add a README.Debian to > warn users of this quirk, but there is no guarantee that people would > read it. > > Any ideas, comments, suggestions from the team? Should the bug remain RC > once 3.5 enters unstable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340375: Subject: kuser destroys all passwords if /etc/shadow isn't present
On Tuesday 22 November 2005 20:23, Charles G Montgomery wrote: > Subject: kuser destroys all passwords if /etc/shadow isn't present > Package: kuser > Version: 4:3.4.2-1 > Severity: grave > Justification: renders package unusable Hello, I forwarded the issue upstream, and a check was added for the /etc/shadow file in the KDE 3.5 branch. The kdeadmin upload that should clear NEW and be in experimental shortly contains this fix. However, as you noted yourself, this doesn't completely resolve the issue, since /etc/shadow could be present but shadow passwords still not in use. Upstream seems to be under the astonishing impression that the ability to disable the use of shadow passwords by clearing "/etc/shadow" from the shadow file text field in Configure KUser is intuitive and clear to users. Even the check for /etc/shadow was added reluctantly, and upstream has stated that he has no intention of adding further checks. So what to do? Having /etc/shadow but not using shadow passwords is probably a pretty rare configuration. We could add a README.Debian to warn users of this quirk, but there is no guarantee that people would read it. Any ideas, comments, suggestions from the team? Should the bug remain RC once 3.5 enters unstable? Cheers, Christopher Martin pgpsg6chPl5Ry.pgp Description: PGP signature
Bug#340375: Subject: kuser destroys all passwords if /etc/shadow isn't present
Subject: kuser destroys all passwords if /etc/shadow isn't present Package: kuser Version: 4:3.4.2-1 Severity: grave Justification: renders package unusable *** Please type your report below this line *** When I attempted to add a new user (for testing purposes), kuser apparently replaced the password field in /etc/passwd with "x" for all users. It then reported it was unable to open /etc/shadow and exited. This left things so that no login by anyone was possible, which made it difficult to repair the damage! I don't use shadow passwords, and there is no /etc/shadow file present. I know of no Debian policy that requires /etc/shadow to be present. If kuser can't deal with a system where /etc/shadow isn't present, it should NOT leave the system unusable and unreparable. I suppose this is related to kuser editing files directly, as discussed in bug#248145. I have not checked what happens if /etc/shadow exists but "/sbin/shadowconfig off" has been executed, because I dislike the sensation of having all logins impossible. If kuser can't behave better, then I think the Debian installation should at least check for the existence of /etc/shadow and, if it's not present, at least warn the user during installation of potential disaster. regards, cgm -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kuser depends on: ii kdelibs4c24:3.4.2-4 core libraries for all KDE applica ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-2 GCC support library ii libqt3-mt 3:3.3.5-1 Qt GUI Library (Threaded runtime v ii libstdc++64.0.2-2The GNU Standard C++ Library v3 kuser recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
