Debian Bug report logs - #1708
`passwd' not interruptible when invoked by `adduser'

Toggle useless messages

Message #10 received at 1708-done@bugs.debian.org (full text, mbox, reply):

From: Christoph Lameter <clameter@waterf.org>

To: 1708-done@bugs.debian.org

Subject: bug has nothing to do with adduser but is a passwd problem

Date: Sun, 22 Sep 1996 21:23:40 -0700 (PDT)

{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{}    Snail Mail:   FTS Box 466, 135 N.Oakland Ave, Pasadena, CA 91182        {}
{}    FISH Internet System Administrator at Fuller Theological Seminary       {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
PGP Public Key  =  FB 9B 31 21 04 1E 3A 33  C7 62 2F C0 CD 81 CA B5 

Message #17 received at 1708-done@bugs.debian.org (full text, mbox, reply):

From: Christoph Lameter <clameter@waterf.org>

To: 1708-done@bugs.debian.org

Subject: Not adduser

Date: Tue, 1 Oct 1996 16:39:57 -0700

Message #24 received at forwarded@bugs.debian.org (full text, mbox, reply):

From: David Engel <david@sw.ods.com>

To: "H.J.Lu" <hjl@gnu.ai.mit.edu>, Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de>

Subject: Re: Bug#1708: `passwd' not interruptible when invoked by `adduser'

Date: Tue, 11 Mar 1997 09:50:10 -0600

Hi Guys,

I'm trying to clean out some old, Debian libc bug reports.  The
getpass function ignores interrupt signals in both libc5 and glibc.
This behavior is not documented.  Furthermore, the Solaris 2.5.1
manpage says that an interrupt signal will terminate input and send
the interrupt signal to the calling program.  Which behavior is
correct?

David
-- 
David Engel                        ODS Networks
david@sw.ods.com                   1001 E. Arapaho Road
(972) 234-6400                     Richardson, TX  75081

Message #29 received at 1708-done@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@fs.tum.de>

To: <10894-done@bugs.debian.org>, <11419-done@bugs.debian.org>, <11504-done@bugs.debian.org>, <15086-done@bugs.debian.org>, <17182-done@bugs.debian.org>, <17270-done@bugs.debian.org>, <18206-done@bugs.debian.org>, <22568-done@bugs.debian.org>, <32774-done@bugs.debian.org>, <13185-done@bugs.debian.org>, <1708-done@bugs.debian.org>, <1774-done@bugs.debian.org>, <2011-done@bugs.debian.org>, <4898-done@bugs.debian.org>, <6516-done@bugs.debian.org>, <6798-done@bugs.debian.org>

Subject: Closing old bugs in libc5

Date: Mon, 19 Mar 2001 15:14:09 +0100 (CET)

libc5 is obsolete and no longer maintained upstream for several years.
It's mostly there for old commercial applications and bugs will only be
fixed in the packaging.

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Message #36 received at 1708@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@fs.tum.de>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: <1708@bugs.debian.org>

Subject: Re: Bug#1708 acknowledged by developer (Closing old bugs in libc5)

Date: Mon, 19 Mar 2001 20:26:39 +0100 (CET)

On Mon, 19 Mar 2001, Ian Jackson wrote:

> Debian Bug Tracking System writes ("Bug#1708 acknowledged by developer          (Closing old bugs in libc5)"):
> > This is an automatic notification regarding your Bug report
> > #1708: `passwd' not interruptible when invoked by `adduser',
> > which was filed against the libc5 package.
> ...
> > libc5 is obsolete and no longer maintained upstream for several years.
> > It's mostly there for old commercial applications and bugs will only be
> > fixed in the packaging.
>
> You have clearly not examined these bug reports to see whether they
> should be reassigned to more recent libcs.

???

The following happens when I press ^D when asked for the password (on my
up-to-date unstable system):

<--  snip  -->

# adduser
Enter a username to add: aaa
Adding user aaa...
Adding new group aaa (1002).
Adding new user aaa (1002) with group aaa.
Creating home directory /home/aaa.
Copying files from /etc/skel
Enter new UNIX password:

passwd: Conversation error
adduser: `passwd aaa' returned error code 10.  Aborting.
Cleaning up.
Removing directory `/home/aaa'
Removing user `aaa'.
Removing group `aaa'.
groupdel: group aaa does not exist
#

<--  snip  -->


That means I can't reproduce your problem.
How can you reproduce it?


> I shall reopen them now.
>
> Ian.

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Message #41 received at 1708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Adrian Bunk <bunk@fs.tum.de>

Cc: <1708@bugs.debian.org>

Subject: Re: Bug#1708 acknowledged by developer (Closing old bugs in libc5)

Date: Tue, 20 Mar 2001 10:54:07 +0000 (GMT)

Adrian Bunk writes ("Re: Bug#1708 acknowledged by developer        (Closing old bugs in  libc5)"):
> That means I can't reproduce your problem.
> How can you reproduce it?

Try ^C rather than ^D.  It completely ignores it, which I think is
unhelpful behaviour.  (^C is the canonical way to interrupt a program,
of course; ^D indicates the user is happy but has no more input.)

Ian.

Message #48 received at 1708-done@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: 1708-done@bugs.debian.org

Subject: getpass() is not buggy

Date: Wed, 18 Apr 2001 15:52:45 -0400

The getpass function is documented in the info page is ignoring certain
signals (SIGINT is one of them) via the ISIG terminal attribute, and
explains the reasoning. It also says to use your own function, if the
glibc one does not suit your needs, giving an example.

getpass is marked by sus-v2 is being "legacy", since it is not something
which the user cannot easily provide themselves. Also, the spec provided
does not say that it has to be interruptable. It merely states that it
may return an error of EINTR. Since glibc's getpass ignore's that
signal, then it does not return such an error. The spec allows for this
to occur.

Because of these reasons, I am marking this bug closed.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Message #53 received at 1708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 1708@bugs.debian.org (Debian Bug Tracking System)

Cc: control@bugs.debian.org (Debian Bug Tracking System)

Subject: Re: Bug#1708 acknowledged by developer (getpass() is not buggy)

Date: Thu, 19 Apr 2001 10:58:05 +0100 (BST)

reopen 1708
thanks

Debian Bug Tracking System writes ("Bug#1708 acknowledged by developer          (getpass() is not buggy)"):
> This is an automatic notification regarding your Bug report
> #1708: `passwd' not interruptible when invoked by `adduser',
> which was filed against the libc6 package.
...
> The getpass function is documented in the info page is ignoring certain
> signals (SIGINT is one of them) via the ISIG terminal attribute, and
> explains the reasoning. It also says to use your own function, if the
> glibc one does not suit your needs, giving an example.

I have two problems with this, and am reopening the report:

Firstly, this is an explanation of why you think the bug isn't in
libc6 - not an explanation of why the bug doesn't exist at all.  The
bug, that passwd is not interruptible, still exists and is still a
bug.  If you felt that the bug was inappropriately assigned to libc6
you should discuss this with the maintainer of passwd.  Closing the
bug was definitely wrong, and you should have known this.

Secondly, your explanation by reference to the spec does not explain
why the spec should not be changed.  In particular, if you talk to the
maintainer of passwd they're likely to say that there should clearly
be some general password-getting function since many programs need to
do this, and they may well ask you to explain why getpass() should not
be that function - and have its spec and implementation improved where
necessary.

Ian.

Message #60 received at 1708@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 1708@bugs.debian.org

Subject: Re: Bug#1708: acknowledged by developer (getpass() is not buggy)

Date: Thu, 19 Apr 2001 10:36:56 -0400

reassign 1708 libpam-modules
thanks

On Thu, Apr 19, 2001 at 10:58:05AM +0100, Ian Jackson wrote:
> reopen 1708
> thanks
> 
> Debian Bug Tracking System writes ("Bug#1708 acknowledged by developer          (getpass() is not buggy)"):
> > This is an automatic notification regarding your Bug report
> > #1708: `passwd' not interruptible when invoked by `adduser',
> > which was filed against the libc6 package.
> ...
> > The getpass function is documented in the info page is ignoring certain
> > signals (SIGINT is one of them) via the ISIG terminal attribute, and
> > explains the reasoning. It also says to use your own function, if the
> > glibc one does not suit your needs, giving an example.
> 
> I have two problems with this, and am reopening the report:
> 
> Firstly, this is an explanation of why you think the bug isn't in
> libc6 - not an explanation of why the bug doesn't exist at all.  The
> bug, that passwd is not interruptible, still exists and is still a
> bug.  If you felt that the bug was inappropriately assigned to libc6
> you should discuss this with the maintainer of passwd.  Closing the
> bug was definitely wrong, and you should have known this.

Changing standards is not a function of the bug tracking system. That's
a function of standards working groups. I'll reassign this to
libpam-modules For all intents, the getpass() function is marked LEGACY
by susv2, and obsolete by the getpass(3) manpage. If you want to propose
a password getting function to a standards body, then by all means do so.

> Secondly, your explanation by reference to the spec does not explain
> why the spec should not be changed.  In particular, if you talk to the
> maintainer of passwd they're likely to say that there should clearly
> be some general password-getting function since many programs need to
> do this, and they may well ask you to explain why getpass() should not
> be that function - and have its spec and implementation improved where
> necessary.

Until a week ago, I was the maintainer of the passwd package. I never
had any problems with this issue. I'm reassigning this since I
don't think there's a bug in libc6. It follows current standards
documents, and its own documentation. The libpam-modules are responsible
for the communication for the password and username.

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Message #79 received at 1708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 1708@bugs.debian.org

Subject: Re: `passwd' not interruptible when invoked by `adduser'

Date: Mon, 27 Aug 2007 02:40:25 -0700

clone 1708 -1
reassign -1 shadow
thanks

This problem is not only a PAM problem.  Even after patching PAM to not
block SIGINT, the signal is still being ignored because passwd/su/login each
also block the signal on their own.

So fixing this would require changes to both pam and shadow.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #86 received at 1708-close@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 1708-close@bugs.debian.org

Subject: Bug#1708: fixed in pam 0.99.7.1-3

Date: Tue, 28 Aug 2007 14:02:05 +0000

Source: pam
Source-Version: 0.99.7.1-3

We believe that the bug you reported is fixed in the latest version of
pam, which is due to be installed in the Debian FTP archive:

libpam-cracklib_0.99.7.1-3_amd64.deb
  to pool/main/p/pam/libpam-cracklib_0.99.7.1-3_amd64.deb
libpam-cracklib_0.99.7.1-3_i386.deb
  to pool/main/p/pam/libpam-cracklib_0.99.7.1-3_i386.deb
libpam-doc_0.99.7.1-3_all.deb
  to pool/main/p/pam/libpam-doc_0.99.7.1-3_all.deb
libpam-modules_0.99.7.1-3_amd64.deb
  to pool/main/p/pam/libpam-modules_0.99.7.1-3_amd64.deb
libpam-modules_0.99.7.1-3_i386.deb
  to pool/main/p/pam/libpam-modules_0.99.7.1-3_i386.deb
libpam-runtime_0.99.7.1-3_all.deb
  to pool/main/p/pam/libpam-runtime_0.99.7.1-3_all.deb
libpam0g-dev_0.99.7.1-3_amd64.deb
  to pool/main/p/pam/libpam0g-dev_0.99.7.1-3_amd64.deb
libpam0g-dev_0.99.7.1-3_i386.deb
  to pool/main/p/pam/libpam0g-dev_0.99.7.1-3_i386.deb
libpam0g_0.99.7.1-3_amd64.deb
  to pool/main/p/pam/libpam0g_0.99.7.1-3_amd64.deb
libpam0g_0.99.7.1-3_i386.deb
  to pool/main/p/pam/libpam0g_0.99.7.1-3_i386.deb
pam_0.99.7.1-3.diff.gz
  to pool/main/p/pam/pam_0.99.7.1-3.diff.gz
pam_0.99.7.1-3.dsc
  to pool/main/p/pam/pam_0.99.7.1-3.dsc



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1708@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Steve Langasek <vorlon@debian.org> (supplier of updated pam package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 28 Aug 2007 06:33:33 -0700
Source: pam
Binary: libpam0g-dev libpam0g libpam-modules libpam-doc libpam-runtime libpam-cracklib
Architecture: source amd64 all i386
Version: 0.99.7.1-3
Distribution: unstable
Urgency: low
Maintainer: Steve Langasek <vorlon@debian.org>
Changed-By: Steve Langasek <vorlon@debian.org>
Description: 
 libpam-doc - Documentation of PAM
 libpam-runtime - Runtime support for the PAM library
 libpam-cracklib - PAM module to enable cracklib support
 libpam-modules - Pluggable Authentication Modules for PAM
 libpam0g   - Pluggable Authentication Modules library
 libpam0g-dev - Development files for PAM
Closes: 1708 95324 153157 325974 331278 439835
Changes: 
 pam (0.99.7.1-3) unstable; urgency=low
 .
   * New patch limits_wrong_strncpy: fix unnecessary manipulations of string
     buffers, including an illegal use of strncpy().  Thanks to Paul Hampson
     for reporting.  Closes: #331278.
   * New patch misc_conv_allow_sigint.patch: allow SIGINT to be handled by the
     application, instead of blocking it when misc_conv is in use and
     preventing users from being able to ^C at any PAM prompt.  Closes: #1708.
   * 024_debian_cracklib_dict_path: default to NULL instead of a specific
     dictionary path when none is defined for consistency with the new upstream
     version of cracklib, and define our path in debian/rules.
   * 055_pam_unix_nullok_secure: document the pam_unix "nullok_secure" option,
     a prereq for forwarding this patch upstream.  Closes: #325974.
   * Create /etc/security/opasswd on new installs or on upgrades from
     0.99.7.1-2 or below, so that users that enable the remember=<n> option to
     pam_unix aren't left unable to change passwords.  Closes: #95324.
   * Fix a couple of thinkos in hurd_no_setfsuid, that were preventing the code
     from compiling on the Hurd still.  Thanks to Michael Banck for the catch.
   * Fix a memory leak in the pam_limits capabilities patch: always
     cap_free() the cap_t before returning from pam_sm_open_session().
     Closes: #153157.
   * libpam0g.postinst, libpam0g.templates: on upgrades from versions
     prior to 0.99.7.1-3, restart known PAM-using services so that they
     get the new libpam symbols, since otherwise the newer PAM modules
     will fail to load.  Postinst taken from libssl0.9.8; thanks to
     Christoph Martin for the fine example!  Closes: #439835.
   * Build-depend on po-debconf to support l10n of the debconf questions
     from the above.
Files: 
 2c175769447891fff65804cec22c14c0 1160 libs optional pam_0.99.7.1-3.dsc
 c3491baa3b6071e36ccddea10a5cf5d7 106141 libs optional pam_0.99.7.1-3.diff.gz
 ae8a1f3cdee6ea299f86552efca02d0b 96698 admin required libpam-runtime_0.99.7.1-3_all.deb
 f670ff97106195c4f3223e1be495eda3 264906 doc optional libpam-doc_0.99.7.1-3_all.deb
 348d201f83c3071208e8fe06795379e8 78640 libs required libpam0g_0.99.7.1-3_amd64.deb
 5622b9fbe54584b01a1c05159f910111 263468 libs required libpam-modules_0.99.7.1-3_amd64.deb
 04745b444718953d8d7d6c3339ffa800 142736 libdevel optional libpam0g-dev_0.99.7.1-3_amd64.deb
 9178a8a3c5cdd22d1c2f520b4d50419b 48064 libs optional libpam-cracklib_0.99.7.1-3_amd64.deb
 9955bd92ed2d303d024381c729a3c06e 75760 libs required libpam0g_0.99.7.1-3_i386.deb
 02a36723213a01788d5255961eb49eb1 251780 libs required libpam-modules_0.99.7.1-3_i386.deb
 b2217b4331dfff81c974757d1fa69c45 140700 libdevel optional libpam0g-dev_0.99.7.1-3_i386.deb
 f1b2305ecd16a4a94043f3a0bb659bf3 48116 libs optional libpam-cracklib_0.99.7.1-3_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG1CdzKN6ufymYLloRAkHfAKC2BiQTMunEqLdrPf/EeLBpEKNAhQCfUAsj
TGB2RH1QSpc3PBRj2XVbrsg=
=dfn9
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.