Debian Bug report logs - #155583
libpam-modules: does unix_chkpwd have to be SUID root?

Toggle useless messages

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

From: Lee Maguire <lee-debian@hexkey.co.uk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libpam-modules: does unix_chkpwd have to be SUID root?

Date: Mon, 5 Aug 2002 22:11:21 +0100

Package: libpam-modules
Version: 0.72-35
Severity: wishlist

As I understand it, on a stand-alone Debian system it is sufficient
for unix_chkpwd to be SGID shadow.

While SUID root may be necessary for alternative password authentication
(NIS+?) I have observed that in some packages (e.g. cdrecord, ssh) where
SUID root isn't necessary the user can choose via debconf.

(possibly defaulting to SUID root with a low-priority option to
 downgrade privileges?)

It's always nice to have one less SUID root program.

Message #8 received at 155583-submitter@bugs.debian.org (full text, mbox, reply):

From: Robert Bihlmeyer <robbe@orcus.priv.at>

To: 155583-submitter@bugs.debian.org

Subject: Re: libpam-modules: does unix_chkpwd have to be SUID root?

Date: 14 Oct 2002 20:20:34 +0200

I tried and unix_chkpwd works fine with the following permissions:

-r-xr-sr-x    1 root     shadow      14984 2002-10-14 20:16 /sbin/unix_chkpwd

-- 
Robbe

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

From: Russell Coker <russell@coker.com.au>

To: Matt Zimmerman <mdz@debian.org>, debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Wed, 12 Nov 2003 15:36:40 +1100

On Wed, 12 Nov 2003 13:47, Matt Zimmerman wrote:
> On Wed, Nov 12, 2003 at 01:23:02PM +1100, Russell Coker wrote:
> > Allowing a RADIUS server to authenticate local users against /etc/shadow
> > is standard and expected functionality IMHO.  I consider any RADIUS
> > server which can't authenticate against the local accounts database to be
> > severely broken.
>
> I disagree; I wouldn't let any of these RADIUS implementations near my
> shadow file.

unix_chkpwd is a reasonable solution to this.

> > One possible solution to this is to have a special GID for non-root
> > programs which are allowed to check passwords.  I would be happy to code
> > this if someone else wants to do the testing...
>
> We already have such a group, named "shadow".  In fact, I don't know why
> unix_chkpwd is setuid root rather than setgid shadow.

Bug report #155583 has been open for over a year.  I have repeated the tests 
of Lee and Robert and verified that it works fine as SETGID rather than 
SETUID.

Also I believe that Lee's statement regarding NIS is incorrect, unix_chkpwd 
only does /etc/shadow.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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

From: Matt Zimmerman <mdz@debian.org>

To: Russell Coker <russell@coker.com.au>

Cc: debian-devel@lists.debian.org, 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Wed, 12 Nov 2003 00:39:08 -0500

On Wed, Nov 12, 2003 at 03:36:40PM +1100, Russell Coker wrote:

> On Wed, 12 Nov 2003 13:47, Matt Zimmerman wrote:
> > We already have such a group, named "shadow".  In fact, I don't know why
> > unix_chkpwd is setuid root rather than setgid shadow.
> 
> Bug report #155583 has been open for over a year.  I have repeated the tests 
> of Lee and Robert and verified that it works fine as SETGID rather than 
> SETUID.
> 
> Also I believe that Lee's statement regarding NIS is incorrect, unix_chkpwd 
> only does /etc/shadow.

I agree completely; this seems long overdue.  Sam, do you have any
reservations about this?

-- 
 - mdz

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

From: Andreas Metzler <ametzler@logic.univie.ac.at>

To: debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Wed, 12 Nov 2003 17:59:09 +0100

On Wed, Nov 12, 2003 at 03:36:40PM +1100, Russell Coker wrote:
> On Wed, 12 Nov 2003 13:47, Matt Zimmerman wrote:
[...] 
> unix_chkpwd is a reasonable solution to this.
>>> One possible solution to this is to have a special GID for
>>> non-root programs which are allowed to check passwords.  I would
>>> be happy to code this if someone else wants to do the testing...

>> We already have such a group, named "shadow".  In fact, I don't
>> know why unix_chkpwd is setuid root rather than setgid shadow.
 
> Bug report #155583 has been open for over a year.  I have repeated
> the tests of Lee and Robert and verified that it works fine as
> SETGID rather than SETUID.
 
> Also I believe that Lee's statement regarding NIS is incorrect, unix_chkpwd 
> only does /etc/shadow.

testing.....

You are wrong, unix_chkpwd does NIS (at least in the szenario I just
tested). After changing unix_chkpwd from 4755 root:root to 2755
root:shadow a NIS user can not unlock the terminal he has just locked
himself with vlock anymore.

The NIS-server is configured with
*                          : *       : shadow.byname    : port
*                          : *       : passwd.adjunct.byname : port

and

MERGE_PASSWD=false
            cu andreas

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

From: Russell Coker <russell@coker.com.au>

To: Andreas Metzler <ametzler@logic.univie.ac.at>, debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 10:43:58 +1100

On Thu, 13 Nov 2003 03:59, Andreas Metzler wrote:
> > Also I believe that Lee's statement regarding NIS is incorrect,
> > unix_chkpwd only does /etc/shadow.
>
> testing.....
>
> You are wrong, unix_chkpwd does NIS (at least in the szenario I just
> tested). After changing unix_chkpwd from 4755 root:root to 2755
> root:shadow a NIS user can not unlock the terminal he has just locked
> himself with vlock anymore.

I've just read the code more carefully.  It seems that the only NIS specific 
code is the following:
if (strcmp(pwd->pw_passwd, "*NP*") == 0) {      /* NIS+ */
  uid_t save_uid;
  save_uid = geteuid();
  seteuid(pwd->pw_uid);
  spwdent = getspnam(name);
  seteuid(save_uid);
  salt = x_strdup(spwdent->sp_pwdp);
} else {
  salt = x_strdup(pwd->pw_passwd);
}

Now if the program is SGID shadow (same as vlock incidentally) then the UID of 
the process should already be the same as pwd->pw_uid and therefore it should 
all work.

Or do you have to be root for getpwnam() to work on NIS accounts?

Could you please do some more tests on this?

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

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 01:15:55 +0100

On Thu, Nov 13, 2003 at 10:43:58AM +1100, Russell Coker wrote:
> On Thu, 13 Nov 2003 03:59, Andreas Metzler wrote:
>>> Also I believe that Lee's statement regarding NIS is incorrect,
>>> unix_chkpwd only does /etc/shadow.

>> testing.....

>> You are wrong, unix_chkpwd does NIS (at least in the szenario I just
>> tested). After changing unix_chkpwd from 4755 root:root to 2755
>> root:shadow a NIS user can not unlock the terminal he has just locked
>> himself with vlock anymore.

> I've just read the code more carefully.  It seems that the only NIS specific 
> code is the following:
> if (strcmp(pwd->pw_passwd, "*NP*") == 0) {      /* NIS+ */
[...]
> } else {
>   salt = x_strdup(pwd->pw_passwd);
> }

This seems to be code for NIS+, not NIS.

> Now if the program is SGID shadow (same as vlock incidentally) then the UID of 
> the process should already be the same as pwd->pw_uid and therefore it should 
> all work.

> Or do you have to be root for getpwnam() to work on NIS accounts?

In certain NIS configurations you can only access the hashed password
if your query to the NIS server comes from a privileged port <=1024,
i.e. afaict yes.

I should have stated this more clearly in my initial mail. I was in a
hurry, sorry.

> Could you please do some more tests on this?

If you tell me what exactly you want me to test I can run the test
(not tomorrow, but soon enough)
           cu andreas
PS: I am subscribed to -devel, please don't cc me, thanks.
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

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

From: Russell Coker <russell@coker.com.au>

To: debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 11:50:05 +1100

On Thu, 13 Nov 2003 11:15, Andreas Metzler <ametzler@downhill.at.eu.org> 
wrote:
> > Or do you have to be root for getpwnam() to work on NIS accounts?
>
> In certain NIS configurations you can only access the hashed password
> if your query to the NIS server comes from a privileged port <=1024,
> i.e. afaict yes.

This is so ugly.

Maybe we should have a debconf option for whether the program in question is 
to be SETUID root or SETGID shadow?  Then the minority of people who use NIS 
can have full functionality, while the majority of people who don't use NIS 
can have better security.

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

From: Henning Makholm <henning@makholm.net>

To: debian-devel@lists.debian.org, 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: 13 Nov 2003 02:06:09 +0100

Scripsit Russell Coker <russell@coker.com.au>

> Maybe we should have a debconf option for whether the program in question is 
> to be SETUID root or SETGID shadow?  Then the minority of people who use NIS 
> can have full functionality, while the majority of people who don't use NIS 
> can have better security.

Would it be feasible to have the program be suid root, but start by
trying to parse /etc/nsswitch.conf and drop root privileges
immediately unless it finds NIS for passwd/shadow?

-- 
Henning Makholm         "Vend dig ikke om! Det er et meget ubehageligt syn!"

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

From: Steve Langasek <vorlon@netexpress.net>

To: debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Wed, 12 Nov 2003 19:54:37 -0600

[Message part 1 (text/plain, inline)]

On Thu, Nov 13, 2003 at 11:50:05AM +1100, Russell Coker wrote:
> On Thu, 13 Nov 2003 11:15, Andreas Metzler <ametzler@downhill.at.eu.org> 
> wrote:
> > > Or do you have to be root for getpwnam() to work on NIS accounts?

> > In certain NIS configurations you can only access the hashed password
> > if your query to the NIS server comes from a privileged port <=1024,
> > i.e. afaict yes.

> This is so ugly.

Last I looked, there wasn't much in NIS that wasn't.  I think the amount
of pain we should put other users through on account of NIS is very
small (e.g., no longer asking about non-md5 passwords on install).

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

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

From: Russell Coker <russell@coker.com.au>

To: debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 17:52:13 +1100

On Thu, 13 Nov 2003 12:54, Steve Langasek <vorlon@netexpress.net> wrote:
> > This is so ugly.
>
> Last I looked, there wasn't much in NIS that wasn't.  I think the amount
> of pain we should put other users through on account of NIS is very
> small (e.g., no longer asking about non-md5 passwords on install).

Sounds reasonable.

I guess we could make it all install for non-NIS systems by default and assume 
that anyone who knows how to get NIS properly installed can sort out the 
necessary changes.

When comparing distributions they sometimes count the number of questions 
asked at installation, by such a comparison Debian does very badly.  While I 
don't think that we should be aiming for a dozen questions on an install, I 
think that we can productively remove some of the less common options.

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

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 10:52:03 +0100

Russell Coker <russell@coker.com.au> wrote:
> On Thu, 13 Nov 2003 11:15, Andreas Metzler <ametzler@downhill.at.eu.org> 
> wrote:
>> > Or do you have to be root for getpwnam() to work on NIS accounts?

>> In certain NIS configurations you can only access the hashed password
>> if your query to the NIS server comes from a privileged port <=1024,
>> i.e. afaict yes.

> This is so ugly.

> Maybe we should have a debconf option for whether the program in
> question is to be SETUID root or SETGID shadow?  Then the minority
> of people who use NIS can have full functionality, while the
> majority of people who don't use NIS can have better security.

Sounds feasible. (Of course if you insist you can already use
dpkg-statoverride today), a patch would look like this:

config
if ! dpkg-statoverride --list /sbin/unix_chkpwd 1>/dev/null 2>&1 ; then
        # check if we are installing suid or not
        RET=false
        db_input medium libpam-modules/unix_chkpwd_SUID_bit || true
        db_go
fi

postinst:
if [ "$1" = "configure" ] ; then
  # do nothing if local admin has overriden the permissions
  if ! dpkg-statoverride --list /sbin/unix_chkpwd 1>/dev/null 2>&1 ; then
    RET=false
    db_get libpam-modules/unix_chkpwd_SUID_bit
    if [ "$RET" = "true" ]; then
      chown root:root /sbin/unix_chkpwd
      chmod 4755 /sbin/unix_chkpwd
    else
      chown root:shadow /sbin/unix_chkpwd
      chmod 2755 /sbin/unix_chkpwd
    fi
  fi
fi

     cu andreas

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

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: debian-devel@lists.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 10:39:15 +0100

Steve Langasek <vorlon@netexpress.net> wrote:
> On Thu, Nov 13, 2003 at 11:50:05AM +1100, Russell Coker wrote:
>> On Thu, 13 Nov 2003 11:15, Andreas Metzler <ametzler@downhill.at.eu.org> 
>> wrote:
>>>> Or do you have to be root for getpwnam() to work on NIS accounts?

>>> In certain NIS configurations you can only access the hashed password
>>> if your query to the NIS server comes from a privileged port <=1024,
>>> i.e. afaict yes.

>> This is so ugly.

> Last I looked, there wasn't much in NIS that wasn't.  I think the amount
> of pain we should put other users through on account of NIS is very
> small (e.g., no longer asking about non-md5 passwords on install).

Just for reference: NIS basically works fine with MD5-passwords as
long as all involved parties (server/clients) could handle them in
their local /etc/shadow or /etc/passwd.
               cu andreas

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

From: Matt Zimmerman <mdz@debian.org>

To: Russell Coker <russell@coker.com.au>

Cc: debian-devel@lists.debian.org, 155583@bugs.debian.org

Subject: Re: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 13:47:11 -0500

On Thu, Nov 13, 2003 at 05:52:13PM +1100, Russell Coker wrote:

> On Thu, 13 Nov 2003 12:54, Steve Langasek <vorlon@netexpress.net> wrote:
> > > This is so ugly.
> >
> > Last I looked, there wasn't much in NIS that wasn't.  I think the amount
> > of pain we should put other users through on account of NIS is very
> > small (e.g., no longer asking about non-md5 passwords on install).
> 
> Sounds reasonable.
> 
> I guess we could make it all install for non-NIS systems by default and
> assume that anyone who knows how to get NIS properly installed can sort
> out the necessary changes.
> 
> When comparing distributions they sometimes count the number of questions
> asked at installation, by such a comparison Debian does very badly.  While
> I don't think that we should be aiming for a dozen questions on an
> install, I think that we can productively remove some of the less common
> options.

I think a single "Will you be using NIS?" question would be justified; this
could provide defaults for md5 vs. crypt passwords and setuid-ness of
unix_chkpwd, and so those questions could be suppressed by default.

-- 
 - mdz

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

From: Matt Zimmerman <mdz@debian.org>

To: debian-devel@lists.debian.org, 155583@bugs.debian.org

Subject: Re: Bug#155583: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 14:06:49 -0500

On Wed, Nov 12, 2003 at 05:59:09PM +0100, Andreas Metzler wrote:

> You are wrong, unix_chkpwd does NIS (at least in the szenario I just
> tested). After changing unix_chkpwd from 4755 root:root to 2755
> root:shadow a NIS user can not unlock the terminal he has just locked
> himself with vlock anymore.
> 
> The NIS-server is configured with
> *                          : *       : shadow.byname    : port
> *                          : *       : passwd.adjunct.byname : port
> 
> and
> 
> MERGE_PASSWD=false

The code does this:

                        if (strcmp(pwd->pw_passwd, "*NP*") == 0) {      /* NIS+ 
*/
                                uid_t save_uid;

                                save_uid = geteuid();
                                seteuid(pwd->pw_uid);
                                spwdent = getspnam(name);
                                seteuid(save_uid);

                                salt = x_strdup(spwdent->sp_pwdp);
                        } else {
                                salt = x_strdup(pwd->pw_passwd);
                        }

Obviously, seteuid isn't going to work when we aren't root.

-- 
 - mdz

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

From: Sam Hartman <hartmans@debian.org>

To: Russell Coker <russell@coker.com.au>

Cc: debian-devel@lists.debian.org, 155583@bugs.debian.org

Subject: Re: Bug#155583: radiusd-freeradius history and future

Date: Thu, 13 Nov 2003 23:16:59 -0500

>>>>> "Matt" == Matt Zimmerman <mdz@debian.org> writes:

    Matt> I think a single "Will you be using NIS?" question would be
    Matt> justified; this could provide defaults for md5 vs. crypt
    Matt> passwords and setuid-ness of unix_chkpwd, and so those
    Matt> questions could be suppressed by default.

I disagree.  Debian is sufficiently hard to install that developers of
security software I've asked to install it have been frustrated to the
point of not using it by the number of questions.  I believe adding questions about NIS would be inappropriate.

I'd rather see a solution where we have some nis support package that
makes unix_chkpwd setuid root when that support package is installed.

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

From: Matt Zimmerman <mdz@debian.org>

To: Sam Hartman <hartmans@debian.org>, 155583@bugs.debian.org

Cc: Russell Coker <russell@coker.com.au>, debian-devel@lists.debian.org

Subject: Re: Bug#155583: radiusd-freeradius history and future

Date: Fri, 14 Nov 2003 11:37:45 -0500

On Thu, Nov 13, 2003 at 11:16:59PM -0500, Sam Hartman wrote:

> >>>>> "Matt" == Matt Zimmerman <mdz@debian.org> writes:
> 
>     Matt> I think a single "Will you be using NIS?" question would be
>     Matt> justified; this could provide defaults for md5 vs. crypt
>     Matt> passwords and setuid-ness of unix_chkpwd, and so those
>     Matt> questions could be suppressed by default.
> 
> I disagree.  Debian is sufficiently hard to install that developers of
> security software I've asked to install it have been frustrated to the
> point of not using it by the number of questions.  I believe adding
> questions about NIS would be inappropriate.

The method I described, if implemented, would not change the number of
questions asked in a default install.  The NIS question would essentially
replace the md5 question, which would remain at default unless the user asks
to see every single question.

> I'd rather see a solution where we have some nis support package that
> makes unix_chkpwd setuid root when that support package is installed.

This would be even better.

-- 
 - mdz

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

From: Steve Langasek <vorlon@netexpress.net>

To: debian-devel@lists.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: Bug#155583: radiusd-freeradius history and future

Date: Fri, 14 Nov 2003 12:46:02 -0600

[Message part 1 (text/plain, inline)]

On Fri, Nov 14, 2003 at 11:37:45AM -0500, Matt Zimmerman wrote:
> On Thu, Nov 13, 2003 at 11:16:59PM -0500, Sam Hartman wrote:

> > >>>>> "Matt" == Matt Zimmerman <mdz@debian.org> writes:

> >     Matt> I think a single "Will you be using NIS?" question would be
> >     Matt> justified; this could provide defaults for md5 vs. crypt
> >     Matt> passwords and setuid-ness of unix_chkpwd, and so those
> >     Matt> questions could be suppressed by default.

> > I disagree.  Debian is sufficiently hard to install that developers of
> > security software I've asked to install it have been frustrated to the
> > point of not using it by the number of questions.  I believe adding
> > questions about NIS would be inappropriate.

> The method I described, if implemented, would not change the number of
> questions asked in a default install.  The NIS question would essentially
> replace the md5 question, which would remain at default unless the user asks
> to see every single question.

Oh, but the md5 question was already one too many, which is why it's
already been removed for sarge. :)

> > I'd rather see a solution where we have some nis support package that
> > makes unix_chkpwd setuid root when that support package is installed.

> This would be even better.

Yes, that doesn't sound like a bad solution.

-- 
Steve Langasek
postmodern programmer

[Message part 2 (application/pgp-signature, inline)]

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

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: debian-devel@lists.debian.org

Subject: Re: Bug#155583: radiusd-freeradius history and future

Date: Fri, 14 Nov 2003 21:10:52 +0100

Steve Langasek <vorlon@netexpress.net> wrote:
> On Fri, Nov 14, 2003 at 11:37:45AM -0500, Matt Zimmerman wrote:
[...]
>> > I'd rather see a solution where we have some nis support package that
>> > makes unix_chkpwd setuid root when that support package is installed.

>> This would be even better.

> Yes, that doesn't sound like a bad solution.

The package-name is nis, but afaict the only possible solutions for
this would reqire nis to use dpkg-statoveride, whis is imho ugly.
             cu andreas

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

From: Martin Pitt <mpitt@debian.org>

To: 155583@bugs.debian.org, nis@packages.debian.org

Cc: control@bugs.debian.org

Subject: Ubuntu patch for derooting /sbin/unix_chkpwd

Date: Tue, 2 Aug 2005 15:19:10 +0200

[Message part 1 (text/plain, inline)]

tag 155583 patch
thanks

In Ubuntu we now install unix_chkpwd with setgid shadow by default to
eliminate this rather useless suid root program:

  http://patches.ubuntu.com/patches/pam.unix_chkpwd-deroot.diff

However, as mentioned in the bug trail, this would break nis, so we
patched nis as well to change back the permissions of unix_chkpwd to
setuid root while nis is installed:

  http://patches.ubuntu.com/patches/nis.unix_chkpwd-deroot.diff

I talked to Scott James Remnant, and we agreed that using a
statoverride is the least ugly way to achieve this.

Of course this requires coordination between the nis and the pam
maintainers, and the conflicts Ubuntu added need to be adapted
accordingly.

We use theses patches for several weeks now without any problems.

Thanks for considering and have a nice day!

Martin

-- 
Martin Pitt              http://www.piware.de
Ubuntu Developer   http://www.ubuntulinux.org
Debian Developer        http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

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

From: Steve Langasek <vorlon@debian.org>

To: Martin Pitt <mpitt@debian.org>, 155583@bugs.debian.org

Cc: nis@packages.debian.org, srivasta@debian.org

Subject: Re: Bug#155583: Ubuntu patch for derooting /sbin/unix_chkpwd

Date: Tue, 2 Aug 2005 15:46:19 -0700

[Message part 1 (text/plain, inline)]

Hi Martin,

On Tue, Aug 02, 2005 at 03:19:10PM +0200, Martin Pitt wrote:
> In Ubuntu we now install unix_chkpwd with setgid shadow by default to
> eliminate this rather useless suid root program:

>   http://patches.ubuntu.com/patches/pam.unix_chkpwd-deroot.diff

Well, I've recently received a patch that originates from Red Hat's PAM
tree, which adds support for using unix_chkpwd as a password *changing*
helper as well.  I'm actually not too thrilled with the code itself, but it
seems that at least some people believe this is necessary for
SELinux-enabled systems with certain policies; and using unix_chkpwd as a
password-changing helper does seem to preclude dropping the suid bit, since
/etc/shadow is not group-writable (nor should it be).

I'm happy to see the privileges of unix_chkpwd reduced, as long as we can do
this in a way that's also meets the needs of SELinux users.

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

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

From: Martin Pitt <mpitt@debian.org>

To: Steve Langasek <vorlon@debian.org>, 155583@bugs.debian.org, nis@packages.debian.org, srivasta@debian.org

Subject: Re: Bug#155583: Ubuntu patch for derooting /sbin/unix_chkpwd

Date: Wed, 3 Aug 2005 08:30:36 +0200

[Message part 1 (text/plain, inline)]

Hi Steve!

Steve Langasek [2005-08-02 15:46 -0700]:
> Hi Martin,
> 
> On Tue, Aug 02, 2005 at 03:19:10PM +0200, Martin Pitt wrote:
> > In Ubuntu we now install unix_chkpwd with setgid shadow by default to
> > eliminate this rather useless suid root program:
> 
> >   http://patches.ubuntu.com/patches/pam.unix_chkpwd-deroot.diff
> 
> Well, I've recently received a patch that originates from Red Hat's PAM
> tree, which adds support for using unix_chkpwd as a password *changing*
> helper as well.

Ugh, thanks for the note. Does that obsolete /usr/bin/passwd? Or do
the two converge now? I don't really see the point in having two
programs that change your password. If /usr/bin/passwd could be
eliminated completely (or replaced with a symlink), then that would be
nice as well, of course. :-)

Thanks,

Martin

-- 
Martin Pitt              http://www.piware.de
Ubuntu Developer   http://www.ubuntulinux.org
Debian Developer        http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

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

From: Steve Langasek <vorlon@debian.org>

To: Martin Pitt <mpitt@debian.org>

Cc: 155583@bugs.debian.org, nis@packages.debian.org, srivasta@debian.org

Subject: Re: Bug#155583: Ubuntu patch for derooting /sbin/unix_chkpwd

Date: Wed, 3 Aug 2005 01:17:49 -0700

On Wed, Aug 03, 2005 at 08:30:36AM +0200, Martin Pitt wrote:
> Hi Steve!

> Steve Langasek [2005-08-02 15:46 -0700]:
> > Hi Martin,

> > On Tue, Aug 02, 2005 at 03:19:10PM +0200, Martin Pitt wrote:
> > > In Ubuntu we now install unix_chkpwd with setgid shadow by default to
> > > eliminate this rather useless suid root program:

> > >   http://patches.ubuntu.com/patches/pam.unix_chkpwd-deroot.diff

> > Well, I've recently received a patch that originates from Red Hat's PAM
> > tree, which adds support for using unix_chkpwd as a password *changing*
> > helper as well.

> Ugh, thanks for the note. Does that obsolete /usr/bin/passwd? Or do
> the two converge now? I don't really see the point in having two
> programs that change your password. If /usr/bin/passwd could be
> eliminated completely (or replaced with a symlink), then that would be
> nice as well, of course. :-)

It wouldn't obsolete /usr/bin/passwd; passwd would continue to be a
PAM-based application, which when calling to pam_unix *could* use
unix_chkpwd for the writes to /etc/shadow.  This would remove the need for
an suid-root passwd in the common case, but I suppose the main perceived
advantage is in not requiring other applications that support PAM password
changing (e.g., sshd) to have direct write access to /etc/shadow.

I can see their point, but damn if this isn't an ugly way to do it.  I'd
much rather see movement toward a BSD auth solution, where the entire
pam_unix module is behind an exec barrier, but I don't exactly have time to
refactor all the existing PAM modules in Debian for that...

-- 
Steve Langasek
postmodern programmer

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

From: Matt Zimmerman <mdz@debian.org>

To: Steve Langasek <vorlon@debian.org>, 155583@bugs.debian.org

Cc: Martin Pitt <mpitt@debian.org>, nis@packages.debian.org, srivasta@debian.org

Subject: Re: Bug#155583: Ubuntu patch for derooting /sbin/unix_chkpwd

Date: Wed, 3 Aug 2005 08:30:47 -0700

On Wed, Aug 03, 2005 at 01:17:49AM -0700, Steve Langasek wrote:
> I can see their point, but damn if this isn't an ugly way to do it.  I'd
> much rather see movement toward a BSD auth solution, where the entire
> pam_unix module is behind an exec barrier, but I don't exactly have time to
> refactor all the existing PAM modules in Debian for that...

It seems much more sensible to me to create an suid-root unix_setpwd than to
overload unix_chkpwd, given that its sole purpose is to be small, simple and
auditable.

-- 
 - mdz

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

From: Mark Brown <broonie@debian.org>

To: Martin Pitt <mpitt@debian.org>

Cc: 155583@bugs.debian.org

Subject: Re: Ubuntu patch for derooting /sbin/unix_chkpwd

Date: Thu, 4 Aug 2005 12:33:31 +0100

On Tue, Aug 02, 2005 at 03:19:10PM +0200, Martin Pitt wrote:

> Of course this requires coordination between the nis and the pam
> maintainers, and the conflicts Ubuntu added need to be adapted
> accordingly.

I haven't looked at the patch yet but assuming it's just adding the
appropriate deps and calls to dpkg-statoverride it shouldn't be a
problem to add it to NIS - just give me a bit of a heads up.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

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

From: Steve Langasek <steve.langasek@canonical.com>

To: 155583@bugs.debian.org

Cc: nis@packages.debian.org

Subject: Re: libpam-modules: does unix_chkpwd have to be SUID root?

Date: Fri, 25 Jul 2008 17:44:22 -0700

[Message part 1 (text/plain, inline)]

clone 155583 -1
tags -1 = patch
reassign -1 nis
title -1 nis: please use dpkg-statoverride for /sbin/unix_chkpwd
severity -1 important
user ubuntu-devel@lists.ubuntu.com
usertags -1 ubuntu-patch origin-ubuntu intrepid
thanks

Hi Mark,

So the latest upstream version of Linux-PAM, which I'm now merging into
Debian, has split out the selinux password updating functionality into a
separate binary (which doesn't need to be suid in any case); so I think it's
time for Debian to move forward with dropping /sbin/unix_chkpwd to sgid
shadow by default.

At this point in time, I believe this would be the correct thing to do for
lenny even if the nis package were not updated to match; however, a patch is
readily available, so I don't think it should be a problem to get both
packages updated for lenny (and I'm happy to NMU nis if you would like). 
The patch from the Ubuntu nis package is attached.

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

[nis-chkpwd.patch (text/x-diff, attachment)]

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

From: Mark Brown <broonie@debian.org>

To: Steve Langasek <steve.langasek@canonical.com>

Cc: 155583@bugs.debian.org, 492426@bugs.debian.org

Subject: Re: libpam-modules: does unix_chkpwd have to be SUID root?

Date: Sat, 26 Jul 2008 10:41:11 +0100

severity 492426 wishlist
tag 492426 + pending
thanks

On Fri, Jul 25, 2008 at 05:44:22PM -0700, Steve Langasek wrote:

> So the latest upstream version of Linux-PAM, which I'm now merging into
> Debian, has split out the selinux password updating functionality into a

Oh, good - I think that's the last Ubuntu diff here.

> The patch from the Ubuntu nis package is attached.

> +                if OVR=$(dpkg-statoverride --list /sbin/unix_chkpwd) && \
> +                    [ "$OVR" == "root root 4755 /sbin/unix_chkpwd" ]; then

There's a bug about this bashism which has been open in the Ubuntu
package for quite some time - it'd be nice if that could be fixed,
especially given the use of dash in Ubuntu.  I've done this in the
Debian package now.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

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

From: Steve Langasek <steve.langasek@canonical.com>

To: Mark Brown <broonie@debian.org>

Cc: 155583@bugs.debian.org, 492426@bugs.debian.org

Subject: Re: libpam-modules: does unix_chkpwd have to be SUID root?

Date: Sat, 26 Jul 2008 13:20:22 -0700

On Sat, Jul 26, 2008 at 10:41:11AM +0100, Mark Brown wrote:
> severity 492426 wishlist
> tag 492426 + pending
> thanks

> On Fri, Jul 25, 2008 at 05:44:22PM -0700, Steve Langasek wrote:

> > So the latest upstream version of Linux-PAM, which I'm now merging into
> > Debian, has split out the selinux password updating functionality into a

> Oh, good - I think that's the last Ubuntu diff here.

According to the changelog in Ubuntu, there's one other:

+    - remove stop links from rc0 and rc6

But perhaps you've integrated a similar patch in your working tree now?

> > The patch from the Ubuntu nis package is attached.

> > +                if OVR=$(dpkg-statoverride --list /sbin/unix_chkpwd) && \
> > +                    [ "$OVR" == "root root 4755 /sbin/unix_chkpwd" ]; then

> There's a bug about this bashism which has been open in the Ubuntu
> package for quite some time - it'd be nice if that could be fixed,
> especially given the use of dash in Ubuntu.  I've done this in the
> Debian package now.

Ok - I don't think that should be a problem, whoever does the Ubuntu merge
next should do the obvious thing and take your version of the change.

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

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

From: Mark Brown <broonie@debian.org>

To: Steve Langasek <steve.langasek@canonical.com>, 492426@bugs.debian.org

Cc: 155583@bugs.debian.org

Subject: Re: Bug#492426: libpam-modules: does unix_chkpwd have to be SUID root?

Date: Sun, 27 Jul 2008 12:54:08 +0100

On Sat, Jul 26, 2008 at 01:20:22PM -0700, Steve Langasek wrote:
> On Sat, Jul 26, 2008 at 10:41:11AM +0100, Mark Brown wrote:

> > Oh, good - I think that's the last Ubuntu diff here.

> According to the changelog in Ubuntu, there's one other:

> +    - remove stop links from rc0 and rc6

> But perhaps you've integrated a similar patch in your working tree now?

No, no such change in Debian.  Oh, well.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

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

From: Steve Langasek <vorlon@debian.org>

To: 155583-close@bugs.debian.org

Subject: Bug#155583: fixed in pam 1.0.1-1

Date: Wed, 30 Jul 2008 04:17:03 +0000

Source: pam
Source-Version: 1.0.1-1

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_1.0.1-1_amd64.deb
  to pool/main/p/pam/libpam-cracklib_1.0.1-1_amd64.deb
libpam-doc_1.0.1-1_all.deb
  to pool/main/p/pam/libpam-doc_1.0.1-1_all.deb
libpam-modules_1.0.1-1_amd64.deb
  to pool/main/p/pam/libpam-modules_1.0.1-1_amd64.deb
libpam-runtime_1.0.1-1_all.deb
  to pool/main/p/pam/libpam-runtime_1.0.1-1_all.deb
libpam0g-dev_1.0.1-1_amd64.deb
  to pool/main/p/pam/libpam0g-dev_1.0.1-1_amd64.deb
libpam0g_1.0.1-1_amd64.deb
  to pool/main/p/pam/libpam0g_1.0.1-1_amd64.deb
pam_1.0.1-1.diff.gz
  to pool/main/p/pam/pam_1.0.1-1.diff.gz
pam_1.0.1-1.dsc
  to pool/main/p/pam/pam_1.0.1-1.dsc
pam_1.0.1.orig.tar.gz
  to pool/main/p/pam/pam_1.0.1.orig.tar.gz



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 155583@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.8
Date: Mon, 28 Jul 2008 13:56:26 -0700
Source: pam
Binary: libpam0g libpam-modules libpam-runtime libpam0g-dev libpam-cracklib libpam-doc
Architecture: source all amd64
Version: 1.0.1-1
Distribution: unstable
Urgency: low
Maintainer: Steve Langasek <vorlon@debian.org>
Changed-By: Steve Langasek <vorlon@debian.org>
Description: 
 libpam-cracklib - PAM module to enable cracklib support
 libpam-doc - Documentation of PAM
 libpam-modules - Pluggable Authentication Modules for PAM
 libpam-runtime - Runtime support for the PAM library
 libpam0g   - Pluggable Authentication Modules library
 libpam0g-dev - Development files for PAM
Closes: 155583 203222 367834 382987 403718 404836 421010 442049 444427 451722 454237 469635 470137 484249 491821
Changes: 
 pam (1.0.1-1) unstable; urgency=low
 .
   * New upstream version.
     - pam_limits: bound RLIMIT_NICE from below. Closes: #403718.
     - pam_mail: set the MAIL variable even when .hushlogin is set.
       Closes: #421010.
     - new minclass option introduced for pam_cracklib.  Closes: #454237.
     - fix a failure to check the string length when matching usernames in
       pam_group.  Closes: #444427.
     - fix setting shell security context in pam_selinux.  Closes: #451722.
     - use --disable-audit, to avoid libaudit being linked in
       accidentally
     - pam_unix now supports SHA-256 and SHA-512 password hashes.
       Closes: #484249, LP: #245786.
     - pam_rhosts_auth is dropped upstream (closes: #382987); add a compat
       symlink to pam_rhosts to support upgrades for a release, and give a
       warning in NEWS.Debian.
     - new symbol in libpam.so.0, pam_modutil_audit_write; shlibs bump, and
       do another round of service restarts on upgrade.
     - pam_unix helper is now called whenever an unprivileged process
       tries and fails to query a user's account status.  Closes: #367834.
   * Drop patches 006_docs_cleanup, 015_hurd_portability,
     019_pam_listfile_quiet, 024_debian_cracklib_dict_path, 038_support_hurd,
     043_pam_unix_unknown_user_not_alert, 046_pam_group_example,
     no_pthread_mutexes, limits_wrong_strncpy, misc_conv_allow_sigint.patch,
     pam_tally_audit.patch, 057_pam_unix_passwd_OOM_check, and
     065_pam_unix_cracklib_disable which have been merged upstream.
   * Patch 022_pam_unix_group_time_miscfixes: partially merged upstream;
     now is really just "pam_group_miscfixes".
   * Patch 007_modules_pam_unix partially superseded upstream; stripping
     hpux-style expiry information off of password fields is now supported.
   * New patch pam_unix_thread-safe_save_old_password.patch, to make sure all
     our getpwnam() use in pam_unix is thread-safe (fixes an upstream
     regression)
   * New patch pam_unix_fix_sgid_shadow_auth.patch, fixing an upstream
     regression which prevents sgid shadow apps from being able to authenticate
     any more because the module forces use of the helper and the helper won't
     allow authentication of arbitrary users.  This change does mean we're
     going to be noisier for the time being in an SELinux environment, which
     should be addressed but is not a regression on Debian.
   * New patch pam_unix_dont_trust_chkpwd_caller.patch, rolling back an
     upstream change that causes unix_chkpwd to assume that setuid(getuid())
     is sufficient to drop permissions and attempt any authentication on
     behalf of the user.
   * The password-changing helper functionality for SELinux systems has been
     split out into a separate unix_update binary, so at long last we can
     change unix_chkpwd to be sgid shadow instead of suid root.
     Closes: #155583.
     - Update the lintian override to match.
   * Install the new unix_update helper into libpam-modules.
   * Use a pristine upstream tarball instead of repacking; requires various
     changes to debian/rules and debhelper files.
   * Replace the Vcs-Svn field with a Vcs-Bzr field; jumping ship from svn,
     and how!
   * Debconf translations:
     - Romanian, thanks to Igor Stirbu <igor.stirbu@gmail.com>
       (closes: #491821)
   * Add libpam0g.symbols, for finer-grained package dependencies with
     dpkg-gensymbols.
   * Fix debian/copyright to list the known copyright holders
   * Fix up the doc-base sections for the libpam-doc documentation, "Apps"
     should not be part of the section name
   * Also fix up whitespace issues in the doc-base abstracts
   * Fix a typo in the libpam0g-dev description.
   * 027_pam_limits_better_init_allow_explicit_root: RLIM_INFINITY is also
     invalid for RLIMIT_NOFILE, so when resetting the limits for a new session,
     use the kernel default of 1024 instead.  Closes: #404836.
   * Create /etc/environment on initial install of libpam-modules (or on
     upgrade from an old version), to quell warnings in the logs about it
     being missing.  Closes: #442049.
   * 026_pam_unix_passwd_unknown_user: drop a redundant, and broken, check for
     the NSS source of our user; this was preventing password changes for NIS
     users, which otherwise should have worked.  Closes: #203222, LP: #9224.
   * New patch do_not_check_nis_accidentally: respect the 'nis' option
     (set or unset) when looking up the user's password entry for password
     changes.  Thanks to Quentin Godfroy <godfroy@clipper.ens.fr> for the
     patch.  Closes: #469635.
   * Drop patch 049_pam_unix_sane_locking, which upon review is not needed;
     it reduces the length of time we hold the lock, but at the expense of
     being able to enforce minimum times between password changes.
   * debian/watch: upstream has hit 1.0, so we're no longer in a "pre"
     directory.  Fix up the regex for uscan.
   * Fix the libpam0g-dev examples directory to not include a gratuitous
     .cvsignore file.
   * New patch, pam.d-manpage-section, to fix the manpage references to
     point to section 5 instead of section 8.
   * Update patch PAM-manpage-section to fix the references to pam(7) from
     other manpages.  Closes: #470137.
   * Add debian/README.source documenting that this package uses quilt.
   * Bump Standards-Version to 3.8.0.
   * Fix a bug in the uid-restoring code in the hurd_no_setfsuid patch; thanks
     to Tomas Mraz <tmraz@redhat.com> for indirectly bringing this to my
     attention
Checksums-Sha1: 
 b00c2cba90e31d76ea37816cf35561b3ccadca38 1427 pam_1.0.1-1.dsc
 28e0a4646c5ccb76adfc266f37f3ba3a2618d121 1597124 pam_1.0.1.orig.tar.gz
 c6d17f8e72b36a5beaee4a3feacf881515030394 144019 pam_1.0.1-1.diff.gz
 39ad2943dd7427875c31b04382b5ac025008519b 164914 libpam-runtime_1.0.1-1_all.deb
 65713c47db324137128367a3d5dc8d1b733d6025 285868 libpam-doc_1.0.1-1_all.deb
 6f61782d85044bd47485c6a2d9ea4dd2ca7adb24 107508 libpam0g_1.0.1-1_amd64.deb
 79238ba15156c08c9accc7bf363c5ad5058f5d44 298568 libpam-modules_1.0.1-1_amd64.deb
 180c22c005e91bb5e84b9ee0558e7e770aeaac82 162128 libpam0g-dev_1.0.1-1_amd64.deb
 a2f3b53c07c36402cfb6992f01982483db211f3b 64318 libpam-cracklib_1.0.1-1_amd64.deb
Checksums-Sha256: 
 1a21fda99ed677bbc1a96cc8d723b2f3e6c396b64bdcbfba90c133bcaf71d430 1427 pam_1.0.1-1.dsc
 10c503a5c42c5a570f5d2734c5f2996ca7559602701d5fe7fc44aef549c183af 1597124 pam_1.0.1.orig.tar.gz
 05fc2d49f1cf7832d764c7fcb4ab18a57893f26b35f55f772be9408af5e368ce 144019 pam_1.0.1-1.diff.gz
 b50601ac08f4081f319fdebe613003e3105087431034db73d9502d7e5dc1cf1d 164914 libpam-runtime_1.0.1-1_all.deb
 cda345cf4beb9e16d993cb7015aa578aae4653b0b97cef873f62a618f9a60564 285868 libpam-doc_1.0.1-1_all.deb
 5c0b68c19781604b06948edd0991d1b69632a481637bc73f97e4e39d1afb80f7 107508 libpam0g_1.0.1-1_amd64.deb
 9aab2558c85cd6c36f63f37d5b10f4302702f3d6c6ff04a91e01e133a54abf32 298568 libpam-modules_1.0.1-1_amd64.deb
 570afa8221de9ac65262f04e89888961325de30730907ed4b1861e9be77283f8 162128 libpam0g-dev_1.0.1-1_amd64.deb
 6e134cd3ff4fba651602cebca1d536c6193c521605360b4509670e95edceace7 64318 libpam-cracklib_1.0.1-1_amd64.deb
Files: 
 04ad642d85d596162521a4ffd09056e3 1427 libs optional pam_1.0.1-1.dsc
 bcaa5d9bf84137e0d128b2ff9b63b1d7 1597124 libs optional pam_1.0.1.orig.tar.gz
 76f3db9dcffbb8035a5730d176156674 144019 libs optional pam_1.0.1-1.diff.gz
 1cef1607354f804dc1fab832f90009b2 164914 admin required libpam-runtime_1.0.1-1_all.deb
 f56b374c6f5ce979eac4d29cf027be3e 285868 doc optional libpam-doc_1.0.1-1_all.deb
 fa233f51a67969fe14f884abbe1f8520 107508 libs required libpam0g_1.0.1-1_amd64.deb
 644b1b261e3c3ba2508af3b80afc226c 298568 libs required libpam-modules_1.0.1-1_amd64.deb
 a144ddb475ffa7b1ea589003e8ee885b 162128 libdevel optional libpam0g-dev_1.0.1-1_amd64.deb
 dbc7406a794e940c21423c5561efbcaa 64318 libs optional libpam-cracklib_1.0.1-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFIj+kDKN6ufymYLloRAkTcAJ439wbpuxSC4MJ6bxArhGfK2k5qngCggWc3
lcN/vP31rMFDyra/1e11e10=
=yd9G
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.