Bug#1072297: [Pkg-shadow-devel] Bug#1072297: lastlog(8) man page: stray XML markup

[Serge E. Hallyn]

On Fri, May 31, 2024 at 07:27:22PM +0200, Jakub Wilk wrote:
> Package: login
> Version: 1:4.13+dfsg1-1+b1
> Severity: minor
> 
> I stumbled upon this:
> 
>$ man lastlog.8 | grep -w term
>   Having high UIDs can create problems when handling the 
>   /var/log/lastlog with external tools. Although the
> 
> I suppose this XML markup shouldn't be there.

Yes, that looks like a simple xml misunderstanding.  I'll remove that
upstream, thanks.

Bug#1068229: [Pkg-shadow-devel] Bug#1068229: login: remove lastlog, remove pam_lastlog.so from PAM config [patch]

[Serge E. Hallyn]

Thanks.  Applied to https://salsa.debian.org/debian/shadow

On Thu, May 30, 2024 at 02:32:24AM +0200, Chris Hofstaedtler wrote:
> Control: tags 1068229 + patch
> 
> Hi,
> 
> here's a patch to achieve the requested changes.
> 
> When this is uploaded, we can have lastlog2 take over.
> 
> Please let me know about your plan on uploading.
> 
> Chris
> 

> diff -Nru shadow-4.13+dfsg1/debian/changelog 
> shadow-4.13+dfsg1/debian/changelog
> --- shadow-4.13+dfsg1/debian/changelog2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/changelog2024-05-30 02:23:58.0 
> +0200
> @@ -1,3 +1,11 @@
> +shadow (1:4.13+dfsg1-4.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Drop pam_lastlog.so from config. (Closes: #1068229)
> +  * Stop installing lastlog binary.
> +
> + -- Chris Hofstaedtler   Thu, 30 May 2024 02:23:58 +0200
> +
>  shadow (1:4.13+dfsg1-4) unstable; urgency=medium
>  
>[ Helmut Grohne ]
> diff -Nru shadow-4.13+dfsg1/debian/login.install 
> shadow-4.13+dfsg1/debian/login.install
> --- shadow-4.13+dfsg1/debian/login.install2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/login.install2024-05-30 02:23:58.0 
> +0200
> @@ -2,6 +2,5 @@
>  usr/share/locale/*/LC_MESSAGES/shadow.mo
>  sbin/nologin usr/sbin
>  usr/bin/faillog
> -usr/bin/lastlog
>  usr/bin/newgrp
>  bin/login usr/bin
> diff -Nru shadow-4.13+dfsg1/debian/login.manpages 
> shadow-4.13+dfsg1/debian/login.manpages
> --- shadow-4.13+dfsg1/debian/login.manpages   2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/login.manpages   2024-05-30 02:23:58.0 
> +0200
> @@ -4,7 +4,6 @@
>  usr/share/man/*/man5/faillog.5
>  usr/share/man/*/man5/login.defs.5
>  usr/share/man/*/man8/faillog.8
> -usr/share/man/*/man8/lastlog.8
>  usr/share/man/*/man8/nologin.8
>  usr/share/man/man1/login.1
>  usr/share/man/man1/newgrp.1
> @@ -12,5 +11,4 @@
>  usr/share/man/man5/faillog.5
>  usr/share/man/man5/login.defs.5
>  usr/share/man/man8/faillog.8
> -usr/share/man/man8/lastlog.8
>  usr/share/man/man8/nologin.8
> diff -Nru shadow-4.13+dfsg1/debian/login.pam 
> shadow-4.13+dfsg1/debian/login.pam
> --- shadow-4.13+dfsg1/debian/login.pam2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/login.pam2024-05-30 02:23:58.0 
> +0200
> @@ -77,10 +77,6 @@
>  # (Replaces the use of /etc/limits in old login)
>  sessionrequired   pam_limits.so
>  
> -# Prints the last login info upon successful login
> -# (Replaces the `LASTLOG_ENAB' option from login.defs)
> -sessionoptional   pam_lastlog.so
> -
>  # Prints the status of the user's mailbox upon successful login
>  # (Replaces the `MAIL_CHECK_ENAB' option from login.defs). 
>  #
> diff -Nru shadow-4.13+dfsg1/debian/not-installed 
> shadow-4.13+dfsg1/debian/not-installed
> --- shadow-4.13+dfsg1/debian/not-installed2024-02-04 21:28:27.0 
> +0100
> +++ shadow-4.13+dfsg1/debian/not-installed2024-05-30 02:23:58.0 
> +0200
> @@ -15,6 +15,7 @@
>  etc/pam.d/useradd
>  etc/pam.d/userdel
>  etc/pam.d/usermod
> +usr/bin/lastlog
>  usr/bin/sg
>  usr/lib/*/libsubid.la
>  usr/sbin/logoutd
> @@ -25,6 +26,7 @@
>  usr/share/man/*/man3/getspnam.3
>  usr/share/man/*/man3/shadow.3
>  usr/share/man/*/man5/suauth.5
> +usr/share/man/*/man8/lastlog.8
>  usr/share/man/*/man8/logoutd.8
>  usr/share/man/man1/groups.1
>  usr/share/man/man1/logoutd.1
> @@ -32,5 +34,6 @@
>  usr/share/man/man3/getspnam.3
>  usr/share/man/man3/shadow.3
>  usr/share/man/man5/suauth.5
> +usr/share/man/man8/lastlog.8
>  usr/share/man/man8/logoutd.8
>  

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Serge E. Hallyn]

On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote:
> Hi OpenSSH, shadow Maintainers,
> 
> On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote:
> > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> > > It seems desirable to ship liblastlog2 in trixie, considering that the
> > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> > > recorded in /var/log/lastlog.
> > 
> [..]
> > At the same time, all traditional writing to /var/log/lastlog should
> > stop.
> > 
> > So, after some of the current fog clears, src:util-linux could
> > introduce new binary packages (at least libpam-lastlog2), but
> > src:pam would need to add it to the common-* config files.
> > 
> > Does this seem right?
> 
> Answering my own question, not quite.
> 
> Apparently, traditionally we have:
> 
> * sshd writes to /var/log/lastlog by itself.
> * login has pam_lastlog.so in its PAM snippet. 
> 
> Both of these would need to be replaced by pam_lastlog2.so. I don't
> really know what the other distros are doing right now, and/or if
> we should align on this.
> 
> So we could either put pam_lastlog2.so into a common-* file from
> src:pam, or openssh and shadow should switch their setup.
> 
> What do we all think about that?

Hi Chris,

It doesn't look like upstream shadow is specifying pam_lastlog.so,
but debian login does.

Putting pam_lastlog2.so into a common-* from src:pam sounds like a good
solution.

thanks,
-serge

Bug#1064940: [Pkg-shadow-devel] Bug#1064940: vipw's manpage does not document ~/.selected_editor

[Serge E. Hallyn]

Thanks.  This is new to me - I see that debian/rules sets that as the
default.

Note that vipw will not use sensible-editor, or ask you what you want
for it, if VISUAL or EDITOR is set in your environment.  Would you
mind adding that to your manpage patch?

thanks,
-serge

On Wed, Feb 28, 2024 at 12:07:50AM +, Toni via Pkg-shadow-devel wrote:
> Package: passwd
> Version: 1:4.13+dfsg1-1+b1
> Severity: minor
> Tags: patch
> 
> 
> Hi,
> 
> the 'vipw' program uses a file that isn't documented. The attached patch
> should fill this gap, although I haven't tried to build the package with
> it.
> 
> 
> Enjoy,
> Toni
> 
> 
> 
> -- System Information:
> Debian Release: 12.5
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-18-amd64 (SMP w/12 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages passwd depends on:
> ii  libaudit1   1:3.0.9-1
> ii  libc6   2.36-9+deb12u4
> ii  libcrypt1   1:4.4.33-2
> ii  libpam-modules  1.5.2-6+deb12u1
> ii  libpam0g1.5.2-6+deb12u1
> ii  libselinux1 3.4-1+b6
> ii  libsemanage23.4-1+b5
> 
> Versions of packages passwd recommends:
> ii  sensible-utils  0.0.17+nmu1
> 
> passwd suggests no packages.
> 
> -- no debconf information

> diff --git a/man/vipw.8.xml b/man/vipw.8.xml
> index 4caddcb..9775af7 100644
> --- a/man/vipw.8.xml
> +++ b/man/vipw.8.xml
> @@ -77,6 +77,11 @@
>vi
>1.
>  
> +
> +On the first run, this program asks you for an editor and stores your
> +selection in ~/.selected_editor. If the editor mentioned therein does
> +not exist on your system, the program will fall back to using 'nano'.
> +
>
>  
>
> @@ -210,6 +215,9 @@
>
>   gshadow5
>
> +  
> +  
> ~/.selected_editor5
> +  
>
>   login.defs5
>,

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1059915: [Pkg-shadow-devel] Bug#1059915: DEP17: move login and shadowconfig to /usr

[Serge E. Hallyn]

Hi,

fwiw this looks good to me.

thanks,
-serge

On Wed, Jan 03, 2024 at 02:59:32PM +0100, Helmut Grohne wrote:
> Source: shadow
> Version: 1:4.13+dfsg1-3
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2
> 
> Hi,
> 
> We want to finalize the /usr-merge transition via DEP17 by moving all
> files to /usr. shadow is involved at this time, because login is
> installed by debootstrap. I'm attaching a patch that moves both login
> and shadowconfig. It seems fairly harmless to me and I think it can go
> to unstable directly. This patch should not be included in
> bookworm-backports or earlier. If you want to support backports, please
> use dh_movetousr instead.
> 
> Helmut

> diff --minimal -Nru shadow-4.13+dfsg1/debian/changelog 
> shadow-4.13+dfsg1/debian/changelog
> --- shadow-4.13+dfsg1/debian/changelog2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/changelog2024-01-03 11:41:32.0 
> +0100
> @@ -1,3 +1,10 @@
> +shadow (1:4.13+dfsg1-3.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * DEP17: Move login and shadowconfig to /usr. (Closes: #-1)
> +
> + -- Helmut Grohne   Wed, 03 Jan 2024 11:41:32 +0100
> +
>  shadow (1:4.13+dfsg1-3) unstable; urgency=medium
>  
>* Team upload
> diff --minimal -Nru shadow-4.13+dfsg1/debian/login.install 
> shadow-4.13+dfsg1/debian/login.install
> --- shadow-4.13+dfsg1/debian/login.install2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/login.install2024-01-03 11:00:47.0 
> +0100
> @@ -4,4 +4,4 @@
>  usr/bin/faillog
>  usr/bin/lastlog
>  usr/bin/newgrp
> -bin/login
> +bin/login usr/bin
> diff --minimal -Nru shadow-4.13+dfsg1/debian/passwd.install 
> shadow-4.13+dfsg1/debian/passwd.install
> --- shadow-4.13+dfsg1/debian/passwd.install   2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/passwd.install   2024-01-03 11:01:01.0 
> +0100
> @@ -1,5 +1,5 @@
>  debian/default/useradd etc/default
> -debian/shadowconfig sbin
> +debian/shadowconfig usr/sbin
>  usr/bin/chage
>  usr/bin/chfn
>  usr/bin/chsh
> diff --minimal -Nru shadow-4.13+dfsg1/debian/rules 
> shadow-4.13+dfsg1/debian/rules
> --- shadow-4.13+dfsg1/debian/rules2023-10-15 19:10:52.0 +0200
> +++ shadow-4.13+dfsg1/debian/rules2024-01-03 11:00:01.0 +0100
> @@ -42,7 +42,7 @@
>   dh_install -a
>  ifeq ($(DEB_HOST_ARCH_OS),hurd)
>   # /bin/login is provided by the hurd package.
> - rm -f debian/login/bin/login
> + rm -f debian/login/usr/bin/login
>  endif
>  
>  override_dh_installpam:

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1041547: [Pkg-shadow-devel] Bug#1041547: login: I can login as root without password despite it being forbidden

[Serge E. Hallyn]

On Thu, Jul 20, 2023 at 05:10:14PM +, ircu...@gmail.com wrote:
> Package: login
> Version: 1:4.13+dfsg1-1+b1
> Severity: serious
> X-Debbugs-Cc: ircu...@gmail.com
> 
> Dear Maintainer,
> 
> On a newly installed debian bookworm /usr/share/doc/passwd/NEWS.Debian.gz 
> mentions a new PREVENT_NO_AUTH option that is supposed to prevent login to 
> passwordless accounts.
> 
> The option is found in /etc/login.defs and has the default value:
> PREVENT_NO_AUTH superuser
> 
> I removed root password using `passwd -d root` so that `grep root 
> /etc/shadow` reads:
> root::19519:0:9:7:::
> 
> I can now login to root on a tty just by typing root as the login name. I can 
> also login to root just by typing `su` from a regular user account. 
> "PREVENT_NO_AUTH superuser" has no effect.
> 
> I then changed the option to "PREVENT_NO_AUTH yes", which is supposed to 
> prevent all passwordless account login.
> 
> I created a new user account `useradd -m -s /bin/bash testuser` and deleted 
> its password `passwd -d testuser`. If I run `grep testuser /etc/shadow` it 
> reads:
> testuser::19558:0:9:7:::
> 
> I can now also login to this account on a tty without any password. `su 
> newuser` also doesn't need any password. I can also still login to the root 
> account by doing `su`.
> 
> https://sources.debian.org/src/shadow/1:4.13+dfsg1-1/src/su.c/?hl=504#L504
> 
> and
> 
> https://sources.debian.org/src/shadow/1:4.13+dfsg1-1/src/login.c/?hl=980#L980
> 
> indicate that this should not be possible. It looks like PREVENT_NO_AUTH 
> doesn't do anything at all.
> 
> This was replicated on IRC by another user too.

The shadow code enforcing PREVENT_NO_AUTH is in the !ifdef PAM case.

-serge

Bug#1038861: [Pkg-shadow-devel] Bug#1038861: login updates login.defs, adds options that old groupmod doesn't understand

[Serge E. Hallyn]

On Thu, Jun 22, 2023 at 08:13:24AM +0200, Marc Haber wrote:
> Package: login
> Version: 1:4.13+dfsg1-1+b1
> Severity: minor
> 
> Hi,
> 
> upgrading from bullseye to bookworm, during the "apt upgrade" step, it
> may happen that login updates login.defs and adds the NONEXISTENT and
> PREVENT_NO_AUTH options to login.defs. However, it is not guaranteed
> that passwd gets upgraded quickly afterwards. Old groupmod, from old
> passwd, doesn't understand the new configuration options and logs
> 
> Jun 22 07:38:41 emptybullseye99 groupmod[6828]: unknown configuration item 
> `NONEXISTENT'
> Jun 22 07:38:41 emptybullseye99 groupmod[6828]: unknown configuration item 
> `PREVENT_NO_AUTH'
> 
> Those messages also end up on the console, unfortunately without a
> prefix indicating which program caused the message. It just says
> "configuration error - unknown item NONEXISTENT". If groupmod didn't log to
> syslog as well, I would still be searching.

That does seem annoying, I don't really see any reason for those error
messages.

I filed https://github.com/shadow-maint/shadow/issues/746 about this.

> This shows, for example, when openssh-client tries to rename its ssh
> group to _ssh in postinst between the updates of login and passwd. I
> have also seen this when upgrading udev from bullseye to bookworm as it
> tries to create the new sgx group.
> 
> Functionality is not affected, the operation succeeds, but there is a
> confusing error message on the console.
> 
> Maybe it would be a good idea to have a versioned dependency between
> login and passwd, preventing the case of an old binary not fully
> understanding a new configuration file.
> 
> Greetings
> Marc
> 
> 
> -- System Information:
> Debian Release: 11.7
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.3.7-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages login depends on:
> ii  libaudit1   1:3.0-2
> ii  libc6   2.36-9
> ii  libcrypt1   1:4.4.18-4
> ii  libpam-modules  1.4.0-9+deb11u1
> ii  libpam-runtime  1.4.0-9+deb11u1
> ii  libpam0g1.4.0-9+deb11u1
> 
> login recommends no packages.
> 
> login suggests no packages.
> 
> -- Configuration Files:
> /etc/pam.d/login changed [not included]
> 
> -- no debconf information
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1035918: [Pkg-shadow-devel] Bug#1035918: shadow fr.po update

[Serge E. Hallyn]

On Thu, May 11, 2023 at 09:48:27AM +0200, bu...@no-log.org wrote:
> Package: shadow
> Version: N/A
> Severity: wishlist
> Tags: patch l10n
> 
> Dear Maintainer,
> 
> Please find attached the french updated translation of shadow-man-page,
> proofread by the debian-l10n-french mailing list contributors.
> 
> This file should be put as debian/po/fr.po in your package build tree.

Hi,

Thanks for the update.

Just as a heads-up, we applied this upstream.  We had to update it due to some
format changes.  You can see the result at

curl -L https://github.com/shadow-maint/shadow/pull/727.diff

-serge

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Serge E. Hallyn]

On Mon, Mar 06, 2023 at 08:41:15PM +0100, Bálint Réczey wrote:
> Hi Alejandro,
> 
> 
> Alejandro Colomar  ezt írta (időpont: 2023.
> márc. 5., V, 20:38):
> >
> > Package: passwd
> > Source: shadow
> > Tags: patch
> > X-Debbugs-CC: Bálint Réczey 
> > X-Debbugs-CC: Iker Pedrosa 
> > X-Debbugs-CC: Serge Hallyn 
> > To: sub...@bugs.debian.org
> >
> > Hi Balint,
> >
> > This is my first patch set sent to Debbugs.  Let's see if I do it
> > correctly :).
> >
> > I can't open a MR in Salsa, since my account is still to be approved
> > (I opened it yesterday).  BTW, if you have any contacts there, please
> > have a look at it; the identifier is 'alx' and the associated email is
> > .  I sent a mail to the Salsa admin a week ago but
> > received no response (but I guess they might be busy).
> >
> > Cheers,
> >
> > Alex
> >
> > ---
> >
> > Alejandro Colomar (2):
> >   debian/control: Sort alphabetically package lists
> >   debian/control: Add libbsd-dev and pkg-config
> >
> >  debian/control | 26 ++
> >  1 file changed, 14 insertions(+), 12 deletions(-)
> >
> > Range-diff against v1:
> > -:   > 1:  3d079bd9 debian/control: Sort alphabetically package 
> > lists
> > 1:  48ac3d10 ! 2:  9e323b50 debian/control: Add libbsd-dev and pkg-config
> > @@ debian/control: Build-Depends: bison,
> >  libselinux1-dev [linux-any],
> >  libsemanage-dev [linux-any],
> >  libxml2-utils,
> > -+   pkg-config,
> > ++   pkgconf,
> 
> Thank you for the good intention, but this change won't be needed
> because pkgconf will provide pkg-config according to the plan:
> 
> https://lists.debian.org/debian-devel/2022/07/msg00252.html
> 
> Cheers,
> Balint

Hi Balint,

right now shadow is not depending on either one.  Alex is adding
the pkgconf one.  This diff is between Alex's two diffs, showing
that his first diff had added pkg-config, while v2 is instead doing
pkgconf.

-serge

Bug#1026213: [Pkg-shadow-devel] Bug#1026213: login: $HOME created as 0755 by default

[Serge E. Hallyn]

On Fri, Dec 16, 2022 at 04:14:56PM +0300, Michael Tokarev wrote:
> On Fri, 16 Dec 2022 11:50:18 + debian user  wrote:
> > Package: login
> > Version: 1:4.13+dfsg1-1
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> > X-Debbugs-Cc: r...@localhost.lan, Debian Security Team 
> > 
> > 
> > Dear Maintainer,
> > 
> > please uncomment the line in /etc/login.defs that currently says:
> > 
> > #HOME_MODE  0700
> > 
> > to say:
> > 
> > HOME_MODE  0700
> > 
> > The current settings makes user $HOME directories be created with
> > permissions where other users can read the contents by default.
> 
> I tend to disagree, the default is just fine, all the sensitive
> data (eg, .bash_history, .ssh/ etc) is already protected, there's
> absolutely nothing wrong if the files in home dirs are accessible
> by default, - for example my users complain if they can't show content
> of their own files to other users by default.  On the other hand,
> it is trivial to uncomment the HOME_MODE setting locally if the local
> policy is that users should be paranoid against each other.  It is
> just as easy to set perms of your own home dir at any time, too.
> 
> /mjt

Agreed with mjt.  As an example, unprivileged containers cannot be
started if your subuids cannot at least 'x' $HOME.  And in all the
systems I set up to share with family/friends I want to encourage
not limit sharing.

-serge

Bug#1021745: [Pkg-shadow-devel] Bug#1021745: passwd: /etc/passwd was edited with the wrong shell path

[Serge E. Hallyn]

On Fri, Oct 14, 2022 at 12:18:26AM +0200, Najib B wrote:
> Package: passwd
> Version: 1:4.12.3+dfsg1-1
> Severity: important
> X-Debbugs-Cc: najibbak...@gmail.com
> 
> Dear Maintainer,
> 
> I have just noticed this issue on chsh that I would like to report to you,
> including a solution that I would like to mention.
> 
> --
> # chsh
> Changing the login shell for root
> Enter the new value, or press ENTER for the default
> Login Shell [/bin/zsh]: zsh
> chsh: Warning: zsh does not exist
> 
> exit
> $ sudo chsh
> Password:
> chsh: PAM: Authentication failure`
> ---
> The problem here, is that chsh has accepted "zsh" without checking first, if
> that path exists.

Well no, it clearly checked, and warned you.  You chose to
ignore the warning.  If we refuse to set it, we'll get tons
of bug reports about that.  We could add a fail-on-warning
option I suppose...  But if you choose to ignore the warnings
I don't think you'd use that option.

> After exiting "root" it is not possible to login back.
> The solution is to edit /etc/passwd from this:
> root:x:0:0:root:/root:zsh
> to this:
> root:x:0:0:root:/root:/bin/zsh
> 
> Best regards,
> 
> 
> -- System Information:
> Distributor ID:   Kali
> Description:  Kali GNU/Linux Rolling
> Release:  2022.3
> Codename: kali-rolling
> Architecture: x86_64
> 
> Kernel: Linux 5.18.0-kali7-amd64 (SMP w/3 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages passwd depends on:
> ii  libaudit1   1:3.0.7-1.1
> ii  libc6   2.34-4
> ii  libcrypt1   1:4.4.28-2
> ii  libpam-modules  1.5.2-5
> ii  libpam0g1.5.2-5
> ii  libselinux1 3.4-1+b2
> ii  libsemanage23.4-1+b2
> 
> Versions of packages passwd recommends:
> ii  sensible-utils  0.0.17
> 
> passwd suggests no packages.
> 
> -- no debconf information
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#989919: login: consider setting PAM's user_readenv=1

[Serge E. Hallyn]

On Sat, Apr 09, 2022 at 06:41:47PM +0200, Christoph Anton Mitterer wrote:
> On Sat, 2022-04-09 at 08:20 -0500, Serge E. Hallyn wrote:
> > I wonder whether it was disabled
> > for security reasons?  Is there a debian bug referring to that?
> 
> Hmm could be this...
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611136
> 
> Though I don't quite understand what the attack actually is (or whether
> it was fixed - and if there is no real fix, why the pam manpages still
> don't warn from that option), since any user could just set any var in
> his .bashrc or so

Based on https://www.openwall.com/lists/oss-security/2010/09/27/7
I think the concern was that the user's env file was being read
while fsuid was still root.  I see patches fixing it in pam itself,
so I don't think the default workaround is needed.  Now, arguably,
it is a hairy bit of code, and so defaulting to not reading it
while allowing sites to override is conservative.  I guess someone
should do another code review of at least pam_env.

Bug#868568: [Pkg-shadow-devel] Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Serge E. Hallyn]

So deluser was doing the right thing, right?

The bug is how you got into this state?  Either the adduser for
the high uid should have checked for it being a delegated subuid,
or the adduser which added the subuids to the lower subuid should
have refused when the higher subuid existed as a uid.

On Tue, Mar 08, 2022 at 05:31:41PM +, Ben Harris wrote:
> I ran into a problem very similar to the one described in Debian bug 868568:
> deleting a user with a UID < 10 failed because of a process that was
> running as a user with a UID >= 10.  It turned out to be because the
> larger user ID was recorded in /etc/subuid as a subordinate user-ID for the
> lower-numbered user.  Blanking out /etc/subuid and /etc/subgid caused
> deluser to behave as normal.
> 
> According to login.defs(5), the default range of subuids starts at 10.
> If you're using UIDs over 10 for normal users then you probably want to
> change that (or find a way to disable subordinate user-IDs entirely).
> 
> -- 
> Ben Harris, University of Cambridge Information Services.
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1006216: [Pkg-shadow-devel] Bug#1006216: shadow: suggestions for man 8 groupadd

[Serge E. Hallyn]

Thank you, applied (with tiny changes) at github.com/shadow-maint/shadow.

On Mon, Feb 21, 2022 at 02:24:01PM +0100, Markus Hiereth wrote:
> Source: shadow
> Version: 4.8.1
> Severity: minor
> 
> Hi Serge,
> 
> I withdrew the changes you did not appreciate, kept the ones you did no 
> comment on and used the suggustions you made.
> 
> Attached the respective xml and diff files.
> 
> Best regards
> Markus
> 
> ------------
> 
> "Serge E. Hallyn"  schrieb am 20. Februar 2022 um 10:33
> > On Thu, Feb 17, 2022 at 09:43:59PM +0100, Markus Hiereth wrote:
> > > Hi Serge,
> > > 
> > > today I worked on the message catalogue for groupadd.8
> > > 
> > > I have no problems with understanding or translating this manual
> > > page. Nevertheless there are paragraphs for which I would suggest
> > > alternatives explanations. They are alreay in an attached xml-file.
> > > 
> > > Below, there is a diff with commments that allows you to jugde the
> > > suggestions.
> > > 
> > > Feel free to tell me what changes are welcome.
> > > 
> > > Best regards
> > > Markus
> > > 
> > > 
> > > --- shadow-4.8.1/man/groupadd.8.xml   2019-07-23 17:26:08.0 
> > > +0200
> > > +++ shadow-4.8.1_mh/man/groupadd.8.xml2022-02-17 16:30:14.284465573 
> > > +0100
> > > 
> 
> > > Elsewhere, capital letters are used for such arguments 
> > > 
> > > @@ -72,10 +72,10 @@
> > >  
> > >groupadd
> > >
> > > - options
> > > + OPTIONS
> > >
> > >
> > > - group
> > > + NEWGROUP
> > >
> > >  
> > >
> > > 
> 
> > > These two paragraphs come from section CAVEATS, but I think the are
> > > necessary parts of the section DESCRIPTION
> > > @@ -87,6 +87,15 @@
> > >values from the system. The new group will be entered into the 
> > > system
> > >files as needed.
> > >  
> > > + 
> > > +   Groupnames must start with a lower case letter or an underscore,
> > > +   followed by lower case letters, digits, underscores, or dashes.
> > > +   They can end with a dollar sign.
> > > +   In regular expression terms: [a-z_][a-z0-9_-]*[$]?
> > > + 
> > > + 
> > > +   Groupnames may only be up to _NAME_MAX_LENGTH; characters 
> > > long.
> > > + 
> > >
> > > 
> > > 
> 
> > > Changed due to my different view on the attribute "unique". For me, an
> > > ID that appears only once is an unique but in our context, it always
> > > deals with the relation between names and IDs.
> > > @@ -103,10 +112,11 @@
> > >   
> > > 
> > >   This option causes the command to simply exit with success
> > > - status if the specified group already exists. When used with
> > > - -g, and the specified GID already exists,
> > > - another (unique) GID is chosen (i.e. -g is
> > > - turned off).
> > > + status if the specified group already exists. When used
> > > + with -g and the specified GID already
> > > + exists, another one is chosen. As result, option
> > > + -g is turned off and the GID points in a
> > > + unique way to NEWGROUP.
> > 
> > Sorry, the new language is confusing to me.
> > 
> > Would simply doing 's/another (unique)/a different, unused, /' be
> > clearer to you?
> 
> Yes it would.
> 
>  
> > > I just replaced "this value" with "GID" which is used in the line above
> > > 
> > > @@ -115,8 +125,8 @@
> > > -g, 
> > > --gidGID
> > >   
> > >   
> > > -   The numerical value of the group's ID. This value must be
> > > - unique, unless the -o option is used. The value
> > > +   The numerical value of the group's ID. 
> > > GID 
> > > + must be unique, unless the -o option is used. The 
> > > value
> > >   must be non-negative. The default is to use the smallest ID
> > >   value greater than or equal to GID_MIN and
> > >   greater than every other group.
> > 
> > Ok.
> 
> > > Again, "unique-and-non-unique" stuff 
> > > 
> > > @@ -159,7 +169,10 @@
>

Bug#1006225: [Pkg-shadow-devel] Bug#1006225: edited groups.1.xml and id.1.xml and diff files

[Serge E. Hallyn]

Thank you, applied.

On Wed, Feb 23, 2022 at 10:02:12AM +0100, Markus Hiereth wrote:
> Hi Serge,
> 
> On Mon, 21 Feb 2022 10:30:17 -0600 serge wrote:
> 
> attached groups.1.xml and id.1.xml and patches that replace the
> previously sent on 21 Feb 2022 17:01:53 +0100.
> 
> > Changing 'support' to 'allow' is not good.  And I do think that
> > simply referencing initgroups as I did is better than saying "by
> > using...".  Although I don't believe there's any system out there
> > which does not support initgroups.
> 
> this point made me change the respective paragraph.
> 
> In groups.1.xml in the paragraph above, xml-markup  was
> replaced by  and one removed as not necessary.
> 
> In the SEE ALSO section initgroups(3) was added.
> 
> I hope the two manual pages are done now. Best regards
> Markus


> --- ../../shadow-4.8.1/man/groups.1.xml   2019-07-23 17:26:08.0 
> +0200
> +++ groups.1.xml  2022-02-23 09:39:44.060606763 +0100
> @@ -80,16 +80,17 @@
>The groups command displays the current group names
>or ID values. If the value does not have a corresponding entry in
>/etc/group, the value will be displayed as the
> -  numerical group value. The optional  -  remap='I'>user parameter will display the groups for the
> -  named user.
> +  numerical group value. The optional user
> +  parameter will display the groups for the named user.
>  
>
>  
>
>  NOTE
>  
> -  Systems which do not support concurrent group sets will have the
> +  Systems which do not support supplementary groups (see 
> + initgroups3
> +  ) will have the
>information from /etc/group reported. The user
>must use newgrp or sg to change
>his current real and effective group ID.
> @@ -122,6 +123,9 @@
>,
>
>   getuid2
> +  ,
> +  
> + initgroups3
>.
>  
>


> --- ../../shadow-4.8.1/man/id.1.xml   2019-07-23 17:26:08.0 +0200
> +++ id.1.xml  2022-02-23 09:41:18.64038 +0100
> @@ -79,8 +79,9 @@
>have a corresponding entry in /etc/passwd or
>/etc/group, the value will be displayed without
>the corresponding name. The optional -a flag will
> -  display the group set on systems which support multiple concurrent
> -  group membership.
> +  display the group set on systems which support supplementary groups
> +  (see initgroups
> +  3).
>  
>
>  
> @@ -113,6 +114,9 @@
>,
>
>   getuid2
> +  ,
> +  
> + initgroups3
>
>  
>

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1006848: [Pkg-shadow-devel] Bug#1006848: shadow: improvements for man 8 lastlog

[Serge E. Hallyn]

Thank you, this was already addressed by:

https://github.com/shadow-maint/shadow/commit/726abe8a3260984ead9c2d57e0e5564584dc9f8f

I must have accidentally git-add'd this change from you, which you had
originally sent Dec 22, into my fix for
https://github.com/shadow-maint/shadow/issues/500 , sorry about that.

-serge

Bug#1006208: [Pkg-shadow-devel] Bug#1006208: shadow: trying to improve man pwck

[Serge E. Hallyn]

Thank you.  I will take these diffs (4 I believe?), do one final review, and
push to github.com/shadow-maint/shadow under commits with you as Author.

On Mon, Feb 21, 2022 at 12:40:07PM +0100, Markus Hiereth wrote:
> Source: shadow
> Version: 4.8.1
> Severity: minor
> 
> Dear Serge,
> 
> in accordance your mail from 2022-02-20 (attached) an edited manual xml file 
> and the respective patch file.
> 
> Best regards
> Markus

> On Wed, Feb 16, 2022 at 09:42:34PM +0100, Markus Hiereth wrote:
> > Hi Serge and shadow-utils developers
> > 
> > a few remarks on this manual page. I do not know whether a bug report
> > or a patch are appreciated.
> > 
> > Best regards
> > Markus
> > 
> > 
> > 69   
> > 70 pwck
> > 71 verify integrity of password files
> > 72   
> >  
> > s/verify integrity/verify the integrity
> > 
> > 
> > 
> > 75 
> > 76   pwck
> > 77   options
> > 78   
> > 79 
> > 80   passwd
> > 81 
> > 82 
> > 83   
> > 84 shadow
> > 85   
> > 86 
> > 87   
> > 88 
> > 
> > Replaceables appear in capital letters elsewhere, the name of the
> > argument shall indicate that the name of the two files is not
> > pre-defined, thus write:
> > 
> > 80   PASSWORDFILE
> > 84   SHADOWFILE
> > 
> > 
> > 
> > 128   shadow checks are enabled when a second file
> > 129   parameter is specified or when /etc/shadow
> > 130   exists on the system.
> > 
> > I think "shadow" in "shadow checks" is meant in a general
> > sense. Therefore, if xml is used for mark-up, it should not be the filename 
> > element, but the replaceable element. Or write:
> > 
> > 128 Checks for shadowed password information are enabled when a second 
> > 129 file parameter is specified or when /etc/shadow
> 
> That's all fine.
> 
> > 
> > 
> > 162 checks will still be made. All other errors are warning and the user
> > 163 is encouraged to run the usermod command to 
> > correct
> > 
> > Is "warning" here the participe present from the verb "to warn". In
> > case it is the plural of the noun "a warning", add the plural-s. Or write:
> > 
> > ... All other errors warn the user and encourage him to run the 
> > usermod
> 
> It's just meant as the plural of warning, so simplest would be to just
> say 'All other errors are warnings and..." 
> 
> thanks,
> -serge

> --- shadow-4.8.1/man/pwck.8.xml   2019-10-05 03:23:58.0 +0200
> +++ shadow-4.8.1_mh/man/pwck.8.xml2022-02-21 12:30:25.634576331 +0100
> @@ -68,7 +68,7 @@
>
>
>  pwck
> -verify integrity of password files
> +verify the integrity of password files
>
>
>
> @@ -77,11 +77,11 @@
>options
>
>   
> -   passwd
> +   PASSWORDFILE
>   
>   
> 
> - shadow
> + SHADOWFILE
> 
>   
>
> @@ -123,11 +123,10 @@
>   a valid login shell
>
>  
> -
>  
> -  shadow checks are enabled when a second file
> -  parameter is specified or when /etc/shadow
> -  exists on the system.
> +  Checks for shadowed password information are enabled when the second
> +  file parameter SHADOWFILE is specified or
> +  when /etc/shadow exists on the system.
>  
>  
>These checks are the following:
> @@ -159,7 +158,7 @@
>prompted to delete the entire line. If the user does not answer
>affirmatively, all further checks are bypassed. An entry with a
>duplicated user name is prompted for deletion, but the remaining
> -  checks will still be made. All other errors are warning and the user
> +  checks will still be made. All other errors are warnings and the user
>is encouraged to run the usermod command to correct
>the error.
>  

> 
> 
>"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
> 
> 
> 
> 
> 
> 
> 
> ]>
> 
>   
>   
> 
>   Julianne Frances
>   Haugh
>   Creation, 1992
> 
> 
>   Thomas
>   Kłoczko
>   kloc...@pld.org.pl
>   shadow-utils maintainer, 2000 - 2007
> 
> 
>   Nicolas
>   François
>   nicolas.franc...@centraliens.net
>   shadow-utils maintainer, 2007 - now
> 
>   
>   
> pwck
> 8
> System Management Commands
> shadow-utils
> _UTILS_VERSION;
>   
>   
> pwck
> verify the integrity of password files
>   
>   
>   
> 
>   pwck
>   options
>   
>   
> PASSWORDFILE
>   
>   
> 
>   SHADOWFILE
> 
>   
>   
> 
>   
> 
>   
> DESCRIPTION
> 
>   The pwck command verifies the integrity of the
>   users and authentication information. It checks that all entries in
>   /etc/passwd and /etc/shadow
>   (or the files in
>   /etc/tcb, when USE_TCB is
>   enabled)
>   have the proper format and contain valid data.
>   The user 

Bug#1005253: [Pkg-shadow-devel] Bug#1005253: Bug#1005253: shadow: Improved manual page useradd.8

[Serge E. Hallyn]

On Fri, Feb 11, 2022 at 07:14:27PM +0100, Markus Hiereth wrote:
> Hi Serge,
> 
> "Serge E. Hallyn"  schrieb am 11. Februar 2022 um 18:13
>  
> > Thanks.  The diff is especially helpful.  Although a few of these hunks
> > appear to be just changes to the line breaks.
> 
> > > @@ -219,14 +221,17 @@
> > >   
> > >   
> > > 
> > > - The number of days after a password expires until the account is
> > > - permanently disabled. A value of 0 disables the account as soon
> > > - as the password has expired, and a value of -1 disables the
> > > - feature.
> > > +defines the number of days after the password exceeded its 
> > > maximum
> > > +age where the user is expected to replace this password. The 
> > > value
> > 
> > How about 'number of days after the password exceeded its maximum
> > age during which the user may login by immediately replacing this
> > password. The value is stored in the shadow password file.'
> 
> I also thought that there is something better then "where the user..."

Actually how about "may still login by..."

> > > 
> > >   If not specified, useradd will use the
> > > - default inactivity period specified by the
> > > + default inactivity onset specified by the
> > 
> > "onset" is weird here.
> 
> I looked up in a dictionary: "onset is the first attack or beginning
> (of something bad)" . There are similar usages: "onset of winter", a
> "hard onset" in phonetics, in medicine they speak of the "onset" of a
> disease.
> 
> What do you think of "begin of inactivity"?
> 
> You know I also suggested "grace period". But, expressing it this way,
> the connection to inactivity gets lost.
> 
> I really dislike "inactivity period" as the user does not define the
> duration of inactivity but the number of days he will be able to do
> something against a shift of his account into the inactive state.

Grace period is good, actually.  How about
"grace period before the account becomes inactive"?

> > >   INACTIVE variable in
> > >   /etc/default/useradd, or -1 by default.
> > > 
> > > @@ -237,8 +242,9 @@
> > > -g, 
> > > --gidGROUP
> > >   
> > >   
> > > +   
> > 
> > This i assume is leftover marker to be dropped.
> 
> Sure.
> 
> 
> > > @@ -398,10 +407,18 @@
> > > -o, --non-unique
> > >   
> > >   
> > > -   Allow the creation of a user account with a duplicate 
> > > (non-unique) UID.
> > > +   
> > > + allows the creation of an account with an already existing
> > > + UID.
> > > +   
> > > 
> > >   This option is only valid in combination with the
> > > - -u option.
> > > + -u option. As a user identity
> > > + serves as
> > > + key to map between users on one hand and permissions, file
> > > + ownerships and other aspects that determine the system's
> > > + behavior on the other hand, more than one login name
> > > + will access the account of the given UID.
> > > 
> > >   
> > >
> > > @@ -410,14 +427,25 @@
> > > -p, 
> > > --passwordPASSWORD
> > >   
> > >   
> > > +   
>  
> > Drop this?
> 
> yes
> 
>  
> > > @@ -488,11 +516,11 @@
> > >   
> > >   
> > > 
> > > - The name of the user's login shell. The default is to leave this
> > > - field blank, which causes the system to select the default login
> > > - shell specified by the SHELL variable in
> > > - /etc/default/useradd, or an empty string
> > > - by default.
> > > +sets the path to the user's login shell. Without this option,
> > > +the system will use the SHELL variable 
> > > specified
> > > + in /etc/default/useradd, or, if that is as
> > > + well not set, the field for the login shell in /etc/passwd
> > > + remains empty.
> > > 
> > >   
> > >
> > > @@ -533,13 +561,16 @@
> > >
> > >
> > >   
> > > -   -Z, 
> > > --selinux-userSEUSER
> > > +   -Z, --selinux
> > > +   -userSEUSER
>  
> > Is the line break here accidental?
&g

Bug#1005253: [Pkg-shadow-devel] Bug#1005253: shadow: Improved manual page useradd.8

[Serge E. Hallyn]

On Wed, Feb 09, 2022 at 11:18:04PM +0100, Markus Hiereth wrote:
> Source: shadow
> Version: 4.8.1
> Severity: normal
> 
> Dear Serge,
> 
> attached to this bugreport the improved file useradd.8.xml and a diff.
> A last check is certainly reasonable.

Thanks.  The diff is especially helpful.  Although a few of these hunks
appear to be just changes to the line breaks.

...

> --- shadow-4.8.1/man/useradd.8.xml2020-01-17 16:47:56.0 +0100
> +++ shadow-4.8.1_mh/man/useradd.8.xml 2022-02-09 23:09:13.241687932 +0100
> @@ -143,11 +143,11 @@
>   
>   
> 
> - The default base directory for the system if 
> -dHOME_DIR is not specified.
> - BASE_DIR is
> - concatenated with the account name to define the home directory. 
> - If the -m option is not used,
> - BASE_DIR must exist.
> + The default base directory for the system if
> + -dHOME_DIR
> + is not specified.  BASE_DIR is
> + concatenated with the account name to define the home
> + directory.
> 
> 
>   If this option is not specified, useradd
> @@ -165,7 +165,7 @@
>   
> 
>   Any text string. It is generally a short description of the
> - login, and is currently used as the field for the user's full
> + account, and is currently used as the field for the user's full
>   name.
> 
>   
> @@ -177,12 +177,14 @@
>   
> 
>   The new user will be created using
> - HOME_DIR as the value for the user's
> - login directory. The default is to append the
> + HOME_DIR as the value for the
> + user's login directory. The default is to append the
>   LOGIN name to
> - BASE_DIR and use that as the login
> - directory name. The directory HOME_DIR
> - does not have to exist but will not be created if it is missing.
> + BASE_DIR and use that as the
> + login directory name.  If the directory
> + HOME_DIR does not exist, then
> + it will be created unless the -M option
> + is specified.
> 
>   
>
> @@ -219,14 +221,17 @@
>   
>   
> 
> - The number of days after a password expires until the account is
> - permanently disabled. A value of 0 disables the account as soon
> - as the password has expired, and a value of -1 disables the
> - feature.
> +defines the number of days after the password exceeded its 
> maximum
> +age where the user is expected to replace this password. The 
> value

How about 'number of days after the password exceeded its maximum age
during which the user may login by immediately replacing this password. The 
value
is stored in the shadow password file.'

> +is stored in the shadow password file. An input of 0 will 
> disable an
> +expired password with no delay. An input of -1 will blank the
> +respective field in the shadow password file. See 
> + shadow5
> +for more information.
> 
> 
>   If not specified, useradd will use the
> - default inactivity period specified by the
> + default inactivity onset specified by the

"onset" is weird here.

>   INACTIVE variable in
>   /etc/default/useradd, or -1 by default.
> 
> @@ -237,8 +242,9 @@
> -g, 
> --gidGROUP
>   
>   
> +   

This i assume is leftover marker to be dropped.

> 
> - The group name or number of the user's initial login group. The
> + The name or the number of the user's primary group. The
>   group name must exist. A group number must refer to an already
>   existing group.
> 
> @@ -249,7 +255,7 @@
>   set to yes (or
>   -U/--user-group is specified on the command
>   line), a group will be created for the user, with the same
> - name as her loginname. If the variable is set to
> + name as the loginname. If the variable is set to
>   no (or
>   -N/--no-user-group is specified on the
>   command line), useradd will set the primary group of the new
> @@ -315,14 +321,17 @@
>   (UID_MIN, UID_MAX,
>   UMASK, PASS_MAX_DAYS
>   and others).
> -   
> 
> - Example: 
> -KPASS_MAX_DAYS=-1
> - can be used when creating system account to turn off password
> - aging, even though system account has no password at all.
> - Multiple -K options can be specified, e.g.:
> - 
> -KUID_MIN=100
> - 
> -KUID_MAX=499
> +   
> + Example:
> + -KPASS_MAX_DAYS
> + =-1 can be used
> + when creating an account to turn off password aging.
> + Multiple -K options can be specified,
> + e.g.:
> + -KUID_MIN
> + =100-K
> + UID_MAX=499

Bug#1004472: [Pkg-shadow-devel] Bug#1004472: setup had to be performed / still another problem

[Serge E. Hallyn]

On Fri, Jan 28, 2022 at 12:26:00PM +0100, Markus Hiereth wrote:
> Dear Maintainer,
> 
> the previously reported p
> roblem is quite probable due to fact that the setup instruction on groupmems 
> hadn't be performs.

Ah, I see, manpage recommends setgid.  The instructions in
the manpage are definitely not right, though.  For instance,
they say to chown groupmems after the chmod, but the chown
will negate the chmod.

More importantly, groupmems will try to open a file called
/etc/group.$pid, which it will not be allowed to do just by
virtue of being setuid-group 'groups'.

So yes, the recommended setup can't work.  I wonder whether
anyone actually uses groupmems, or whether we should deprecate
it.

Bug#1004472: [Pkg-shadow-devel] Bug#1004472: groupmem: make authentification clear and check interaction with PAM

[Serge E. Hallyn]

On Fri, Jan 28, 2022 at 11:29:49AM +0100, Markus Hiereth wrote:
> Package: passwd
> Version: 1:4.8.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> 
> Checks made for translation of man 8 groupmems 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Try to invoke groupmems as user and as systemadministrator
> 
>* What was the outcome of this action?
> 
> groupmems asked in both cases for authentification by a password, but does 
> not specify which password is expected. There are three possibilies
> a) root password from root (however, this does not make much sense)
> b) user password for group-owning user (however, this does not make much 
> sense)  
> c) the group's password
> 
> In all cases, I got a PAM authentification failure
> 
>* What outcome did you expect instead?
> 
> A snippet from the logfile is attached
> 
> Best regards
> Markus

This is not a well understood - or well documented - command.

In order for unprivileged users to use groupmems, you must make
it setuid-root:  'chmod u+s /usr/sbin/groupmems'.

After I do this, I as user serge in group serge can do

groupmems -a testuser

to add user testuser to my group serge.  I do have to provide
my own password.

-serge

Bug#989712: Bug#992578: login: please add support for DPKG_ROOT

[Serge E. Hallyn]

On Fri, Sep 24, 2021 at 08:13:22AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi Balint & Serge,
> 
> Quoting Johannes Schauer Marin Rodrigues (2021-08-20 14:45:14)
> > For your convenience, I created a salsa MR that fixes #989712 as well as
> > #992578:
> > 
> > https://salsa.debian.org/debian/shadow/-/merge_requests/15
> > 
> > With this patch, a chroot created with DPKG_ROOT will be bit-by-bit 
> > identical
> > to one created normally, see
> > https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs
> 
> would you mind me applying the above merge request and doing an NMU of shadow?
> 
> Thanks!
> 
> cheers, josch

I'm not package maintainer, but it looks fine to me.

thanks,
-serge

Bug#990350: [Pkg-shadow-devel] Bug#990350: shadow: spurious subuid/subgid entries

[Serge E. Hallyn]

On Sat, Jun 26, 2021 at 05:57:02PM +0200, Christoph Anton Mitterer wrote:
> Source: shadow
> Version: 1:4.8.1-1
> Severity: normal
> 
> 
> Hey there.
> 
> 
> I've recently noted that some of my systems had entries like
> 
> $ cat /etc/subuid
> debian-security-support:10:65536
> lightdm:427680:65536
> _apt:493216:65536
> 
> $ cat /etc/subgid
> debian-security-support:10:65536
> lightdm:427680:65536
> _apt:493216:65536
> 
> 
> While in a freshly debootstrapped chroot, with the same packages installed
> there is neither of these entries.
> 
> I tried to find out whther these packages themselves ever manually added
> the entries, but it doesn't seem so, the just call adduesr.

adduser does not create the entries, but useradd does.  That is because
useradd ships from the shadow soure package, adduser does not.

> After a while of trying I've noted - and this is the main reason for this
> (possible) bug - that entries are created for normal users, but not for
> system users.
> 
> No sure if this is by accident - if not, it should perhaps at least documented
> in the manpage.

The fact that it doesn't happen for system users is not clearly spelled
out, you're right.

> It's still a bit strange though, that I see exactly those entries from
> above in my files, cause when I look at my passwd it has:
> ...
> dnsmasq:x:120:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
> dcmtk:x:122:139::/var/lib/dcmtk/db:/bin/sh
> debian-security-support:x:123:140:Debian security support 
> check,,,:/var/lib/debian-security-support:/bin/false
> uuidd:x:100:102::/run/uuidd:/usr/sbin/nologin
> lightdm:x:128:146:Light Display Manager:/var/lib/lightdm:/bin/false
> _apt:x:129:65534::/nonexistent:/usr/sbin/nologin
> libvirt-qemu:x:64055:127:Libvirt Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin
> ...
> 
> Now let's assume the behaviour of adding subuid/subgid entries started some
> time after my dcmtk was created... and ended for system users some time
> before libvirt-qemu was created...
> then it still doesn't explain why uuidd, which was chronologically likely in
> between, didn't get one.

Could adduser vs useradd explain it?

> Cheers,
> Chris.
> 
> PS: Is there recommended way to add the subuid/subgid entries for all those
> users/groups that were created before this was introduced and which would
> get them, were they created now?

You could script that through usermod, but it might be worth explicitly
adding a usermod flag to say 'only add subuid if it doesn't already
have one'

Bug#834540: RFA: cgmanager -- Central cgroup manager daemon

[Serge E. Hallyn]

On Sun, Sep 06, 2020 at 12:20:24AM +0200, Chris Hofstaedtler wrote:
> * Serge E. Hallyn  [200905 22:19]:
> > On Mon, May 01, 2017 at 04:47:17PM +0200, Michael Biebl wrote:
> > > On Tue, 16 Aug 2016 15:26:46 -0500 "Serge E. Hallyn" 
> > > wrote:
> > For what it's worth, we had retired cgmanager upstream, but I'm now
> > considering either picking it back up, or actually starting from scratch
> > (mainly to drop the 'libnih' dependency which is pretty problematic)
> 
> Apparently the upstream repository is now marked as "Archived".
> 
> > > There is elogind [1], which is a standalone logind implementation which
> > > doesn't require systemd-shim and cgmanager.
> > > This might be an alternative approach to provide the logind interfaces
> > > under sysvinit.
> 
> elogind seems to be in Debian now.
> 
> 
> Serge, what's the current upstream status, or would it make more
> sense to RM cgmanager now?

Indeed, RM makes most sense.

Bug#834540: RFA: cgmanager -- Central cgroup manager daemon

[Serge E. Hallyn]

On Sun, Sep 06, 2020 at 12:20:24AM +0200, Chris Hofstaedtler wrote:
> * Serge E. Hallyn  [200905 22:19]:
> > On Mon, May 01, 2017 at 04:47:17PM +0200, Michael Biebl wrote:
> > > On Tue, 16 Aug 2016 15:26:46 -0500 "Serge E. Hallyn" 
> > > wrote:
> > For what it's worth, we had retired cgmanager upstream, but I'm now
> > considering either picking it back up, or actually starting from scratch
> > (mainly to drop the 'libnih' dependency which is pretty problematic)
> 
> Apparently the upstream repository is now marked as "Archived".
> 
> > > There is elogind [1], which is a standalone logind implementation which
> > > doesn't require systemd-shim and cgmanager.
> > > This might be an alternative approach to provide the logind interfaces
> > > under sysvinit.
> 
> elogind seems to be in Debian now.
> 
> 
> Serge, what's the current upstream status, or would it make more
> sense to RM cgmanager now?

Hi,

the main problem with cgmanager was that it was based on libnih and
so inherited it's penchant for using select(), so it was easy to make
it crash by running out of selectable fds.

Bug#941005: [Pkg-shadow-devel] Bug#941005: Bug#941005: shadow uses obsolete SELinux API

[Serge E. Hallyn]

On Sat, Nov 30, 2019 at 06:47:28PM +0100, Christian Göttsche wrote:
> As the change got merged upstream [1], and upstream releases roughly
> once a year, any chance this gets cherry-picked in the next Debian

Digs aside, the goal is 4x/year, and the next one is scheduled for December.
I was intending to do it next week.

> upload?
> 
> [1] 
> https://github.com/shadow-maint/shadow/commit/a8a921184fdf950194cb887d241e0cbc588759c4
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#857805: [Pkg-shadow-devel] Bug#857805: Bug#857805: shadow: please run the testsuite

[Serge E. Hallyn]

Yes, I'd actually like to have a make option to run the tests in a
container, but I also had some trouble running the tests.  Need a
"known to fail" option per test might be a good way to get moving
on this.  Please keep me in the loop if/as you work on this.

On Mon, Nov 11, 2019 at 04:36:32PM +0100, Bálint Réczey wrote:
> Hi Chris,
> 
> Chris Lamb  ezt írta (időpont: 2019. nov. 11., H, 16:15):
> >
> > Hi Bálint,
> >
> > > I have started experimenting with the tests but they are failing.
> > > Maybe with upstream's help we can enable them for later upstream releases.
> >
> > Good shout. I wonder if it would be helpful to mark them as "known
> > failing" in some way ("|| true" or equivalent...) just so we have the
> > [failing] logs to point upstream at?
> 
> Upstream dropped the tests from the 4.7 release tarball, but this is
> where we are heading.
> I added a link to the failing pipelines.
> 
> Cheers,
> Balint
> 
> >
> >
> > Regards,
> >
> > --
> >   ,''`.
> >  : :'  : Chris Lamb
> >  `. `'`  la...@debian.org chris-lamb.co.uk
> >`-
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#942680: [Pkg-shadow-devel] Bug#942680: passwd: vipw does not resume properly when suspended

[Serge E. Hallyn]

Thanks,

second option sounds nicer but sure is a lot more code.  So I'm
leaning towards the first.  Do you  mind creating a github issue
at github.com/shadow-maint/shadow for this, or would you prefer that
I do it?

-serge

On Sat, Oct 19, 2019 at 04:20:11PM -0600, Todd C. Miller wrote:
> Package: passwd
> Version: 1:4.5-1.1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> If vipw is suspended (e.g. via control-Z) and then resumed, it
> often gets immediately suspended.  This is easier to reproduce
> on a multi-core system.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  
> root@buster:~# /usr/sbin/vipw
> 
> [1]+  Stopped /usr/sbin/vipw
> root@buster:~# fg
> /usr/sbin/vipw
> 
> [1]+  Stopped /usr/sbin/vipw
> 
> root@buster:~# fg
> [vipw resumes on the second fg]
> 
> The problem is that vipw forks a child process and calls waitpid()
> with the WUNTRACED flag.  When the child process (running the editor)
> is suspended, the parent sends itself SIGSTOP to suspend the main vipw
> process.  However, because the main vipw is in the same process group
> as the editor which received the ^Z, the kernel already sent the
> main vipw SIGTSTP.
> 
> If the main vipw receives SIGTSTP before the child, it will be
> suspended and then, once resumed, will proceed to suspend itself
> again.
> 
> There are two main ways to fix this.  I've included patches for
> each approach.
> 
> 1) Don't pass the WUNTRACED flag to waitpid() in vipw.c and
>just assume the main vipw will receive a stop signal from
>the kernel.  This is the simplest fix and works fine for
>stop signals generated due to ^Z.  However, if someone sends
>SIGSTOP to the vipw child process via the kill command, the
>parent vipw will not notice.
> 
> --- vipw.c.orig   2019-10-18 16:19:15.673956247 -0600
> +++ vipw.c.simple_fix 2019-10-18 16:43:04.265583507 -0600
> @@ -325,16 +325,9 @@
>   }
>  
>   for (;;) {
> - pid = waitpid (pid, , WUNTRACED);
> - if ((pid != -1) && (WIFSTOPPED (status) != 0)) {
> - /* The child (editor) was suspended.
> -  * Suspend vipw. */
> - kill (getpid (), SIGSTOP);
> - /* wake child when resumed */
> - kill (pid, SIGCONT);
> - } else {
> + pid = waitpid (pid, , 0);
> + if (pid != -1 || errno != EINTR)
>   break;
> - }
>   }
>  
>   if (-1 == pid) {
> 
> 2) The other option is to run the child process in its own process
>group as the foregroup process group.  That way, control-Z will
>only affect the child process and the parent can use the existing
>logic to suspend the parent.
> 
> 
> --- vipw.c.orig   2019-10-18 16:19:15.673956247 -0600
> +++ vipw.c.pgrp_fix   2019-10-19 12:55:50.526591299 -0600
> @@ -206,6 +206,8 @@
>   struct stat st1, st2;
>   int status;
>   FILE *f;
> + pid_t orig_pgrp, editor_pgrp = -1;
> + sigset_t mask, omask;
>   /* FIXME: the following should have variable sizes */
>   char filebackup[1024], fileedit[1024];
>   char *to_rename;
> @@ -293,6 +295,8 @@
>   editor = DEFAULT_EDITOR;
>   }
>  
> + orig_pgrp = tcgetpgrp(STDIN_FILENO);
> +
>   pid = fork ();
>   if (-1 == pid) {
>   vipwexit ("fork", 1, 1);
> @@ -302,6 +306,14 @@
>   char *buf;
>   int status;
>  
> + /* Wait for parent to make us the foreground pgrp. */
> + if (orig_pgrp != -1) {
> + pid = getpid();
> + setpgid(0, 0);
> + while (tcgetpgrp(STDIN_FILENO) != pid)
> + continue;
> + }
> +
>   buf = (char *) malloc (strlen (editor) + strlen (fileedit) + 2);
>   snprintf (buf, strlen (editor) + strlen (fileedit) + 2,
> "%s %s", editor, fileedit);
> @@ -324,19 +336,50 @@
>   }
>   }
>  
> + /* Run child in a new pgrp and make it the foreground pgrp. */
> + if (orig_pgrp != -1) {
> + setpgid(pid, pid);
> + tcsetpgrp(STDIN_FILENO, pid);
> +
> + /* Avoid SIGTTOU when changing foreground pgrp below. */
> + sigemptyset();
> + sigaddset(, SIGTTOU);
> + sigprocmask(SIG_BLOCK, , );
> + }
> +
>   for (;;) {
>   pid = waitpid (pid, , WUNTRACED);
>   if ((pid != -1) && (WIFSTOPPED (status) != 0)) {
>   /* The child (editor) was suspended.
> -  * Suspend vipw. */
> +  * Restore terminal pgrp and suspend vipw. */
> +

Bug#941005: [Pkg-shadow-devel] Bug#941005: shadow uses obsolete SELinux API

[Serge E. Hallyn]

Thanks.  If you feel so inclined, please feel free to file an issue for it
at github.com/shadow-maint/shadow.  I'll aim to fix this in the next week
or two.  (A lot of travel coming up)

On Mon, Sep 23, 2019 at 01:16:10PM +0200, Laurent Bigonville wrote:
> Source: shadow
> Version: 1:4.7-2
> Severity: normal
> User: selinux-de...@lists.alioth.debian.org
> Usertags: selinux
> 
> Hello,
> 
> It seems that the shadow source package is using obsolete SELinux API,
> for example:
> 
> In file included from passwd.c:46:
> /usr/include/selinux/flask.h:5:2: warning: #warning "Please remove any 
> #include's of this header in your source code." [-Wcpp]
>  #warning "Please remove any #include's of this header in your source code."
>   ^~~
> /usr/include/selinux/flask.h:6:2: warning: #warning "Instead, use 
> string_to_security_class() to map the class name to a value." [-Wcpp]
>  #warning "Instead, use string_to_security_class() to map the class name to a 
> value."
>   ^~~
> In file included from passwd.c:47:
> /usr/include/selinux/av_permissions.h:1:2: warning: #warning "Please remove 
> any #include of this header in your source code." [-Wcpp]
>  #warning "Please remove any #include of this header in your source code."
>   ^~~
> /usr/include/selinux/av_permissions.h:2:2: warning: #warning "Instead, use 
> string_to_av_perm() to map the permission name to a value." [-Wcpp]
>  #warning "Instead, use string_to_av_perm() to map the permission name to a 
> value."
> 
> That should be fixed as it could lead to security issues (or at least
> weakened security) for people using SELinux
> 
> Kind regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#923478: [Pkg-shadow-devel] Bug#923478: initscripts use unsafe `: >` shell command to create files

[Serge E. Hallyn]

On Tue, Apr 16, 2019 at 10:44:21PM +, Dmitry Bogatov wrote:
> 
> [2019-04-14 13:35] Cristian Ionescu-Idbohrn 
> 
> > On Sun, 14 Apr 2019, Dmitry Bogatov wrote:
> > > 
> > > Definitely. But default one is from bin:util-linux.
> >
> > On my sid/unstable:
> >
> > # dpkg -S /bin/login
> > login: /bin/login
> 
> You are right, it is from src:shadow.
> 
> > > So I question, how much of this code is actually necessary:
> > > 
> > >  * group 'utmp' exists on bare system, so conditional is not needed.
> > >  * if /var/run/utmp is missing, nothing bad seems to happen, so does
> > >this code is needed at all?
> > > 
> > > Opinions?
> >
> > IMO, less code is better.  I didn't loog at the source.  But I can 
> > see this:
> >
> > # strings /bin/login | egrep 'utmp|faillog|/'
> > /lib64/ld-linux-x86-64.so.2
> > /usr/share/locale
> > No utmp entry.  You must exec "login" from the lowest level "sh"
> > [...]
> 
> I took a look at source. It seems that this error may only happen if UID != 0.
> I'd better add login maintainers into thread.
> 
> Dear login maintainers, currently we have following core executed during
> boot:
> 
>   # Create /var/run/utmp so we can login.
>   true > /var/run/utmp
>   if grep -q ^utmp: /etc/group
>   then
>   chmod 664 /var/run/utmp
>   chgrp utmp /var/run/utmp
>   fi
> 
> It seems that system boots and works just fine without it. Are there any
> subtle reasons to keep creating /var/run/utmp in initscripts?

Hi,

Is the above pseudocode?  If not, where is that code precisely?

Near as I can tell, if you do not create it, it will never exist,
and pututent entries will not be saved.

> > > PS. Cristian, it seems I did not enough research prior asking you to
> > > make patch and caused labour wasted. I am sorry.
> >
> > No worries.  Still, I would be cautious.  That redirection (with or 
> > without a command prefix) is still questionable, as it _truncates_ the 
> > file (as opposed to just touching it).
> 
> It is under /var/run, which is tmpfs, so it is okay.
> -- 
> Note, that I send and fetch email in batch, once every 24 hours.
>  If matter is urgent, try https://t.me/kaction
>  
> --
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#919317: [Pkg-shadow-devel] Bug#919317: shadow: French documentation translation update

[Serge E. Hallyn]

Hi,

it would be great if you could open a pull request at
https://github.com/shadow-maint/shadow/

Bug#894996: [Pkg-shadow-devel] Bug#894996: Give the path of the directory you are talking about

[Serge E. Hallyn]

Would you mind opening an issue (well, two) at 
github.com/shadow-maint/shadow/issues?

I'll see it there when looking for a task, but am not likely to see this email.

Quoting 積丹尼 Dan Jacobson (jida...@jidanni.org):
> Package: passwd
> Version: 1:4.5-1
> Severity: wishlist
> File: /usr/sbin/useradd
> 
> We see:
> useradd: warning: the home directory already exists.
> 
> The problem is this might be in a forest of other messages,
> so please say what (user's) directory you are talking about.
> Give the exact path.
> 
> We also see
> Not copying any file from skel directory into it.
> 
> If this is from useradd, then I would prefix it
> useradd: Not copying any file from skel directory into it.
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#864736: [Pkg-shadow-devel] Bug#864736: shadow: [INTL:nl] Dutch po file for the shadow package

[Serge E. Hallyn]

On Sat, Jul 15, 2017 at 11:42:22AM +0200, Frans Spiesschaert wrote:
> Serge E. Hallyn schreef op vr 14-07-2017 om 14:06 [-0500]:
> > Thanks, I see it went through some review at 
> > 
> > https://lists.debian.org/debian-l10n-dutch/2017/06/msg00055.html
> > 
> > so happy to take it in the upstream package.  Would you like to
> > post a pull request at github.com/shadow-maint/shadow, 
> 
> > or would
> > you prefer that I post the file for you?
> 
> yes, I would be grateful if you would be willing to do so.

Thanks, done upstream.

Bug#864736: [Pkg-shadow-devel] Bug#864736: shadow: [INTL:nl] Dutch po file for the shadow package

[Serge E. Hallyn]

Thanks, I see it went through some review at 

https://lists.debian.org/debian-l10n-dutch/2017/06/msg00055.html

so happy to take it in the upstream package.  Would you like to
post a pull request at github.com/shadow-maint/shadow, or would
you prefer that I post the file for you?

Bug#859613: cgm gettasks not working properly

[Serge E. Hallyn]

On Tue, Apr 11, 2017 at 03:35:54PM +0200, Svenja Otten wrote:
> Am Wed, 5 Apr 2017 08:51:09 -0500
> schrieb "Serge E. Hallyn" <se...@hallyn.com>:
> 
> > My guess would be that your new login is in a different cgroup from the
> > old.  The path 'user.slice/user-1000.slice' is relative to your current
> > path.  What does
> > 
> > cgm getpidcgroupabs memory $$
> > 
> > show before and after logging back in?
> 
> ok, I tried it out.
> 
> Before logging out:
> --
> root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice
> 13099
> 13101
> 13102
> 13104
> 13105
> 
> root@debian-test:~# cgm getpidcgroupabs memory $$
> /
> --
> 
> After logging back in:
> --
> root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice
> call to cgmanager_get_tasks_sync failed: invalid request
> 
> root@debian-test:~# cgm getpidcgroupabs memory $$
> /user.slice/user-0.slice
> --
> 
> But how how does it work after logging back in?

This is odd.  Are you logging in the same way both times?  how
exactly are you logging in?  (ssh, console, lightdm or the like?)
As which user?  Certainly user-0.slice seems wrong.

You do seem to have multiple things installed at the same time which
can upset each other.  In the first email you showed 'cgget', which
comes from libcgroup, and showed 
/etc/systemd/system/user-1000.slice.d/MemoryLimit.conf
which comes from systemd.

Note that if you are using systemd you should definately not be using
cgmanager.  Both will be trying to set up cgroups and will walk over
each other.  And libcgroup AFAIK is unmaintained for several years now.
It existed before either systemd or cgmanager, so if it is set up to
setup cgroups it will definately cause trouble.

Bug#834540: RFA: cgmanager -- Central cgroup manager daemon

[Serge E. Hallyn]

On Mon, May 01, 2017 at 04:47:17PM +0200, Michael Biebl wrote:
> On Tue, 16 Aug 2016 15:26:46 -0500 "Serge E. Hallyn" <se...@hallyn.com>
> wrote:
> > Package: wnpp
> > Severity: normal
> > 
> > I'd like to pass cgmanager along to a new maintainer, if anyone has
> > an interest in keeping it up.  Upstream (mainly myself) is essentially
> > no longer active, as its use has been supplanted by lxcfs.
> > 
> > If noone has need of it, then perhaps removing it will be the better
> > option.  I will continue to maintain the package in the short term,
> > until either someone takes over or I decide that it can be removed
> > without adversely affecting anyone.
> > 
> 
> I guess the main reason for keeping cgmanager in Debian is to keep
> systemd-shim, thus logind under sysvinit functional.
> So CCing the sysvinit maintainers. Maybe they have an interest in taking
> over the package.

For what it's worth, we had retired cgmanager upstream, but I'm now
considering either picking it back up, or actually starting from scratch
(mainly to drop the 'libnih' dependency which is pretty problematic)

> There is elogind [1], which is a standalone logind implementation which
> doesn't require systemd-shim and cgmanager.
> This might be an alternative approach to provide the logind interfaces
> under sysvinit.
> 
> Regards,
> Michael
> 
> [1] https://github.com/wingo/elogind
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#860818: please package new edbrowse

[Serge E. Hallyn]

Package: edbrowse
Version: 3.6.3

Please package the new version (3.6.3) of edbrowse.

It has some great new features like caching of http files, and M
without a destination buffer.

thanks,
Serge

Bug#857803: [Pkg-shadow-devel] Bug#857803: shadow: Make the sp_lstchg shadow field reproducible.

[Serge E. Hallyn]

Quoting Chris Lamb (la...@debian.org):
> Hi Serge,
> 
> > > > looks ok to me, although, would it be better to fall back to time(NULL)
> > > > if the env variable is invalid?
> > > 
> > > In my experience it is far superior to explicitly error out in this
> > > situation.
> > 
> > My concern is unprivileged users causing unexpected failure in a more
> > privileged script or program by setting an invalid environment variable.
> 
> I hadn't considered that until now. However, I think you have bigger
> problems if you can do that (eg. manipulate PATH!) and tools generally
> do the right thing these days with respect to cleaning the environment
> (eg. sudo).

Right, sudo does but just setuid-root does not.  This env variable
is for reproducible builds, so can we check ruid==0 and ignore the
env variable if not?  Or do the build scripts also run as non-root?

Bug#857803: [Pkg-shadow-devel] Bug#857803: shadow: Make the sp_lstchg shadow field reproducible.

[Serge E. Hallyn]

On Sun, Apr 09, 2017 at 10:07:38AM +0100, Chris Lamb wrote:
> Serge E. Hallyn wrote:
> 
> > looks ok to me, although, would it be better to fall back to time(NULL)
> > if the env variable is invalid?
> 
> In my experience it is far superior to explicitly error out in this
> situation.

My concern is unprivileged users causing unexpected failure in a more
privileged script or program by setting an invalid environment variable.

Bug#857803: [Pkg-shadow-devel] Bug#857803: shadow: Make the sp_lstchg shadow field reproducible.

[Serge E. Hallyn]

Quoting Chris Lamb (la...@debian.org):
> Package: shadow
> Severity: wishlist
> Version: 1:4.4-4
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Hi,
> 
> Attached is the following:
> 
>   commit 2dd84b0ee31e44dc51cba7b7cdc8657bf9ff0a31
>   Author: Chris Lamb 
>   Date:   Wed Mar 15 11:35:35 2017 +0100
>   
>   Make the sp_lstchg shadow field reproducible.
>   
>   The third field in the /etc/shadow file (sp_lstchg) contains the date of
>   the last password change expressed as the number of days since Jan 1, 
> 1970.
>   As this is a relative time, creating a user today will result in:
>   
>  username:17238:0:9:7:::
>   
>   whilst creating the same user tomorrow will result in:
>   
>  username:17239:0:9:7:::
>   
>   This has an impact for the Reproducible Builds[0] project where we aim 
> to
>   be independent of as many elements the build environment as possible,
>   including the current date.
>   
>   This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
>   environment variable (instead of Jan 1, 1970) if available.
>   
>[0] https://reproducible-builds.org/
>[1] https://reproducible-builds.org/specs/source-date-epoch/
>   
>   Signed-off-by: Chris Lamb 
>   
>lib/prototypes.h|  3 ++
>libmisc/Makefile.am |  1 +
>libmisc/gettime.c   | 86 
> +
>src/chpasswd.c  |  2 +-
>src/newusers.c  |  4 +--
>src/passwd.c|  2 +-
>src/useradd.c   |  2 +-
>src/usermod.c   |  4 +--
>8 files changed, 97 insertions(+), 7 deletions(-)
> 
> 
> Regards,

Hi,

looks ok to me, although, would it be better to fall back to time(NULL)
if the env variable is invalid?

Do you want to submit this as a patch to upstream at
github.com/shadow-maint/shadow ?

-serge

> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

> >From 2dd84b0ee31e44dc51cba7b7cdc8657bf9ff0a31 Mon Sep 17 00:00:00 2001
> From: Chris Lamb 
> Date: Wed, 15 Mar 2017 11:35:35 +0100
> Subject: [PATCH] Make the sp_lstchg shadow field reproducible.
> 
> The third field in the /etc/shadow file (sp_lstchg) contains the date of
> the last password change expressed as the number of days since Jan 1, 1970.
> As this is a relative time, creating a user today will result in:
> 
>username:17238:0:9:7:::
> 
> whilst creating the same user tomorrow will result in:
> 
>username:17239:0:9:7:::
> 
> This has an impact for the Reproducible Builds[0] project where we aim to
> be independent of as many elements the build environment as possible,
> including the current date.
> 
> This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
> environment variable (instead of Jan 1, 1970) if available.
> 
>  [0] https://reproducible-builds.org/
>  [1] https://reproducible-builds.org/specs/source-date-epoch/
> 
> Signed-off-by: Chris Lamb 
> ---
>  lib/prototypes.h|  3 ++
>  libmisc/Makefile.am |  1 +
>  libmisc/gettime.c   | 86 
> +
>  src/chpasswd.c  |  2 +-
>  src/newusers.c  |  4 +--
>  src/passwd.c|  2 +-
>  src/useradd.c   |  2 +-
>  src/usermod.c   |  4 +--
>  8 files changed, 97 insertions(+), 7 deletions(-)
>  create mode 100644 libmisc/gettime.c
> 
> diff --git a/lib/prototypes.h b/lib/prototypes.h
> index 7aaf1a6..4808d5d 100644
> --- a/lib/prototypes.h
> +++ b/lib/prototypes.h
> @@ -179,6 +179,9 @@ extern int getrange (char *range,
>   unsigned long *min, bool *has_min,
>   unsigned long *max, bool *has_max);
>  
> +/* gettime.c */
> +extern time_t gettime ();
> +
>  /* get_uid.c */
>  extern int get_uid (const char *uidstr, uid_t *uid);
>  
> diff --git a/libmisc/Makefile.am b/libmisc/Makefile.am
> index 76f3c05..e691dac 100644
> --- a/libmisc/Makefile.am
> +++ b/libmisc/Makefile.am
> @@ -31,6 +31,7 @@ libmisc_a_SOURCES = \
>   getdate.y \
>   getgr_nam_gid.c \
>   getrange.c \
> + gettime.c \
>   hushed.c \
>   idmapping.h \
>   idmapping.c \
> diff --git a/libmisc/gettime.c b/libmisc/gettime.c
> new file mode 100644
> index 000..b0c539b
> --- /dev/null
> +++ b/libmisc/gettime.c
> @@ -0,0 +1,86 @@
> +/*
> + * Copyright (c) 2017, Chris Lamb
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the 

Bug#859613: cgm gettasks not working properly

[Serge E. Hallyn]

Quoting Svenja Otten (ot...@global-village.de):
> Package: cgmanager
> Version: 0.33-2+deb8u2
> 
> Hi,
> 
> the "cgm gettasks" command does not always work as expected.
> I set up a memory limit of 64MB for the user with uid 1000:
> 
> root@debian-test:~# cat /etc/systemd/system/user-1000.slice.d/MemoryLimit.conf
> [Slice]
> MemoryLimit=67108864
> 
> It is set up at reboot, as I can see (with the user logged in):
> 
> root@debian-test:~# cgget -g memory:/user.slice/user-1000.slice
> /user.slice/user-1000.slice:
> memory.pressure_level: 
> memory.use_hierarchy: 1
> memory.swappiness: 60
> memory.memsw.failcnt: 0
> memory.limit_in_bytes: 67108864
> memory.memsw.max_usage_in_bytes: 3182592
> memory.usage_in_bytes: 2670592
> memory.memsw.limit_in_bytes: 18446744073709551615
> memory.failcnt: 0
> memory.force_empty: 
> memory.memsw.usage_in_bytes: 2670592
> memory.max_usage_in_bytes: 3182592
> memory.numa_stat: total=652 N0=652
>   file=0 N0=0
>   anon=652 N0=652
>   unevictable=0 N0=0
>   hierarchical_total=652 N0=652
>   hierarchical_file=0 N0=0
>   hierarchical_anon=652 N0=652
>   hierarchical_unevictable=0 N0=0
> memory.oom_control: oom_kill_disable 0
>   under_oom 0
> memory.stat: cache 0
>   rss 2670592
>   rss_huge 0
>   mapped_file 0
>   writeback 0
>   swap 0
>   pgpgin 1285
>   pgpgout 633
>   pgfault 2744
>   pgmajfault 0
>   inactive_anon 0
>   active_anon 2670592
>   inactive_file 0
>   active_file 0
>   unevictable 0
>   hierarchical_memory_limit 67108864
>   hierarchical_memsw_limit 18446744073709551615
>   total_cache 0
>   total_rss 2670592
>   total_rss_huge 0
>   total_mapped_file 0
>   total_writeback 0
>   total_swap 0
>   total_pgpgin 1285
>   total_pgpgout 633
>   total_pgfault 2744
>   total_pgmajfault 0
>   total_inactive_anon 0
>   total_active_anon 2670592
>   total_inactive_file 0
>   total_active_file 0
>   total_unevictable 0
> memory.move_charge_at_immigrate: 0
> memory.soft_limit_in_bytes: 18446744073709551615
> 
> 
> I can also see the user's tasks:
> 
> root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice
> 2732
> 2734
> 2735
> 2737
> 2738
> 
> But if I then log out with the root user and re-log in, the command fails
> with:
> 
> root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice
> call to cgmanager_get_tasks_sync failed: invalid request
> 
> Can you please check why the command fails after re-log in?

My guess would be that your new login is in a different cgroup from the
old.  The path 'user.slice/user-1000.slice' is relative to your current
path.  What does

cgm getpidcgroupabs memory $$

show before and after logging back in?

Bug#857295: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

[Serge E. Hallyn]

On Tue, Mar 28, 2017 at 06:45:34AM -0400, Stiepan wrote:
> Thanks to the 2.0.7-2 update by Evgeni Golov and his crystal-clear 
> instructions on how to use lxcbr0 with this version, I could confirm that the 
> issue with the host's routing table being affected by changes in the 
> containers' routing tables is not there anymore when using that version (lxc 
> 2.0.7-2 from jessie-backports), which includes the fixes to CVE-2017-5985 
> which were brought in LXC 2.0.7 (upstream).
> 
> This was thus basically a variation of said CVE, which probably doesn't need 
> to be separately numbered as such, the core problem at stake being the same:
> network namespace ownership was not respected by a setuid-root program 
> enabling the user to configure networks as non-root, which is now solved.
> This leads me to a suggestion to the upstream developers: couldn't the same 
> be achieved using specific network-related capabilities, instead of 
> setuid-root, thereby further reducing the risk of lxc-user-nic being 
> exploited and hence, reducing overall attack surface (in unprivileged mode)?
> I have read in https://wiki.ubuntu.com/UserNamespace that the approach of 
> using "targeted capabilities" was then considered. This is probably the 
> closest to what I am suggesting (specifically for lxc-user-nic - the current 
> approach with 1-1 uid mappings seems fine for network-unrelated things).

The targeted capabilities wouldn't help here, because in fact
lxc-user-nic requires privilege against the parent namespace.

-serge

Bug#856902: [Pkg-shadow-devel] Bug#856902: passwd: typos for subuids/subgids long options in usermod(8) man page

[Serge E. Hallyn]

That is surprising, as it's fixed upstream by commit
efbff6a3d9df076da17568c7b5c4787e8fdd3f1c from Nov 9 2016.

Bug#833256: shadow and util-linux

[Serge E. Hallyn]

On Sun, Jan 22, 2017 at 04:18:29PM +0100, Andreas Henriksson wrote:
> Hello again,
> 
> Only focusing on su for this mail, have now studied the previously
> spotted differences between util-linux and shadow in more detail...
> 
> TL;DR NEWS.Debian entry and ignoring the difference is probably safe.

Thanks - I agree switching makes sense for Debian.  Unfortunately it
also sounds like it's worthwhile keeping su separately in shadow upstream
for any non-pam systems which might be out there.  So it sounds like I'm
not useful here :)  and will leave it to the maintainers.  Thanks.

Bug#833256: shadow and util-linux

[Serge E. Hallyn]

Hi,

so it looks like things which are duplicated include:

chfn
chsh
(but not chpasswd?)
newgroup
su
vipw

Do these all work the same way?  (looks like util-linux su has a lot more
options and implements the options shadow's does, good, but it does not honor
all the same login.defs variables?)  Are the manpages sufficient in
util-linux  (I think so)?  What about the internationalization?  (Seems to
be there, at least)

Would you consider implementing other things like usermod in
util-linux?

Ok, I see your (Andreas') tiered proposal.  That sounds good to me,
but then again there is the equivalence question.

Once some of these are out of the debian package, I'll have to check to
make sure no other distros need to switch (gentoo?).  But happy to drop
anything that gets supplanted.

Bug#847173: [Pkg-shadow-devel] Bug#847173: passwd: "usermod -l" don't change "suguid" and "subgid"

[Serge E. Hallyn]

in fairness the manpage does say:

   -l, --login NEW_LOGIN
   The name of the user will be changed from LOGIN to NEW_LOGIN. 
Nothing else is
   changed. In particular, the user's home directory or mail spool 
should probably
   be renamed manually to reflect the new login name.

so I'm not sure what the best action here is, but we should at least add
this to the manpage, if we don't change it.

Quoting Ф И (f_i_2...@list.ru):
> Subject: passwd: "usermod -l" don't change "suguid" and "subgid"
> Package: passwd
> Version: 1:4.2-3.1ubuntu5
> Command
> 
> usermod old_login --login new_login
> 
> does not change old_login
> in files "/etc/suguid" and "/etc/subgid".
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#847491: [pkg-lxc-devel] Bug#847491: lxc: please put the lxc-unshare and lxc-usernsexec tools into their own binary package

[Serge E. Hallyn]

Quoting Johannes Schauer (jo...@debian.org):
> Package: lxc
> Version: 1:2.0.5-1
> Severity: wishlist
> Tags: patch
> 
> Hi,
> 
> with this bug I want to propose a patch against the lxc source package
> which splits out the lxc-unshare and lxc-usernsexec utilities into their
> own binary package. It follows the rationale.
> 
> The lxc package currently contains the two tools lxc-unshare and
> lxc-usernsexec. The only thing that these tools have in common with the
> other lxc tools is that they are prefixed with "lxc-". They are not
> manipulating any lxc containers. Still, these two binaries provide some
> very powerful facilities which are so far unique in Debian: they allow
> to easily enter a new user namespace and unshare several other
> namespaces from within it. There exists the "unshare" utility from the
> util-linux binary package, but that one doesn't offer all the
> functionality that the lxc-unshare and lxc-usernsexec tools offer. One
> important limitation of the unshare tool is, that it doesn't yet allow
> mounting /proc which is a crucial drawback. So even though the
> lxc-unshare tool is described as "mainly provided for testing purposes"
> in its man page, it is so far the only tool in Debian which allows
> easily setting up fully-fledged (including /proc) unprivileged chroots
> from within shell scripts.
> 
> One problem right now is, that to acquire the lxc-unshare and
> lxc-usernsexec utilities, one has to install the full lxc package. Due
> to its dependencies, that can mean up to 95.5 MB of additional disk
> space being required for 74 new packages. Even when installing with
> --no-install-recommends, still 33.2 MB of additional disk space will be
> used for 22 new packages. It would make things much more light-weight if
> the two tools would live in their own binary package because that would
> limit the amount of additionally required disk space to 1172 kB for just
> 5 more packages on top of a minimal installation.
> 
> The attached patch adds the lxc-userns-tools binary package. The name is
> obviously free to be changed to something else. I also let the lxc
> package depend on the lxc-userns-tools package. That way, existing users
> of the lxc package will not see a difference in provided functionality.
> The main overhead and complication that this patch adds are much longer
> *.install files but since you are also using "dh_install --fail-missing"
> there is no way that the list in lxc.install could become outdated in
> the future without you noticing via a build failure.
> 
> What do you think?

Note that lxc-unshare is basically obsoleted by 'unshare' in util-linux.
lxc-usernsexec is, last I checked, still worthwhile, though patching
unshare to have similar uidmap capabilities might be the best way
forward.  (In particular, user-specifiable uid maps, and ability to use
the first mapping found in /etc/subuid)

-serge

Bug#839082: RFA: netcf

[Serge E. Hallyn]

Package: wnpp
Severity: normal

netcf is a library used to modify a host's network configuration.  It is
used for example by the libvirt daemon.

The package should currently be uptodate and has been very low
maintenance, I just fear that as I'm not actively using or watching it
right now I'll let something slip by.

Bug#836653: [Pkg-shadow-devel] Bug#836653: shadow: diff for NMU version 1:4.2-3.2

[Serge E. Hallyn]

Thank you ver much.  Please go ahead and upload.

Bug#836653: shadow: please drop the build dependency on hardening-wrapper

[Serge E. Hallyn]

Quoting Mattia Rizzolo (mat...@debian.org):
> On Sun, Sep 04, 2016 at 01:16:54PM +, Matthias Klose wrote:
> > This package builds using the hardening-wrapper package, which
> > is now replaced by dpkg-dev's DEB_BUILD_MAINT_OPTIONS settings.
> > 
> > Please consider dropping the build dependency of hardening-wrapper
> > and use the DEB_BUILD_MAINT_OPTIONS settings.
> 
> This is particularly annoying for shadow, as it is part of the essential
> set, and it is currently not buildable (hardening-wrapper can't atm be
> coinstalled with current binutils), breaking a set of QA jobs that
> builds the essential set, and messing with statistics.
> 
> I don't think shadow really need hardening-wrapper at all.  The build
> system is a regular autoconf/autotools which respects CFLAGS.
> 
> The compat level is 6, so dh_auto_* won't export them, but you could
> instead set DPKG_EXPORT_BUILDFLAGS and include
> /usr/share/dpkg/buildflags.mk to get them (you need to do so *after* the
> already presetn 'export DEB_BUILD_MAINT_OPTIONS = hardening=+all').
> 
> 
> 
> BTW, Serge: you have staged a bunch of stuff in git already, can we have
> them uploaded?  If you lack a reactive sponsor feel free to email me (or
> contact me over IRC).

Hi,

actually I think everyone was ok with what is staged now, the only
problem is that some extra changes got rolled in which need to be
undone or deal twith (debuild -b complains about upstream changes
mainly to tranlsations).  I've simply not had the time to fix it.
If you have time, that would be great, else yes when I have time (and
network bandwidth - not until next week) to do it I'll need a sponsor,
thanks.

> Otherwise, as people are grumpy for this bug, can I NMU it?  (I'd post a
> proposed patch here, of course, etc).

Sure, I have no objection NMU.

thanks,
-serge

Bug#834540: RFA: cgmanager -- Central cgroup manager daemon

[Serge E. Hallyn]

Package: wnpp
Severity: normal

I'd like to pass cgmanager along to a new maintainer, if anyone has
an interest in keeping it up.  Upstream (mainly myself) is essentially
no longer active, as its use has been supplanted by lxcfs.

If noone has need of it, then perhaps removing it will be the better
option.  I will continue to maintain the package in the short term,
until either someone takes over or I decide that it can be removed
without adversely affecting anyone.

thanks,
-serge

Bug#829001: [Pkg-shadow-devel] Bug#829001: /etc/login.defs: Documentation is wrong about default value of SUB_[UG]ID_COUNT

[Serge E. Hallyn]

Thanks, indeed those should be in sync.  I believe the best is to change
the documentation to read the larger value, as it is a useful range for
containers to use.  I'll aim to get that fix into the next release.

Bug#832047: [Pkg-shadow-devel] Bug#832047: manpage: login.defs lists incorrect default SUB_UID/GID_COUNT values

[Serge E. Hallyn]

Thanks for reporting this bug.  I personally think the best answer
is to change the manpage to specify 65536, as that's the most useful
range for containers.  I'm however not a pkg maintainer, so this is
only my suggestion.

Bug#829509: [Pkg-shadow-devel] Bug#829509: echo * ** *** when typing password, like all moblie apps

[Serge E. Hallyn]

That sounds like an anti-feature, as anyone looking over
your shoulder knows the number of characters.

Bug#829239: [pkg-lxc-devel] Bug#829239: lxc: Document how to set the root password when using the debian template

[Serge E. Hallyn]

Sounds sensible to me.  It also would be a worthwhile endeaver to
put up a blog post summarizing what user/passwords exist in all
the supported templates by default, and what options each provides
to customize that, and then having linuxcontainers.org point to
that blog post.

You wouldn't need to do it for all the templates yourself - I think
if you put out a call for content to lxc-users you would get
contributions.

But a readme.debian is a great start :)

Bug#825948: fix

[Serge E. Hallyn]

A package with the fix is uploaded to

https://mentors.debian.net/debian/pool/main/e/edbrowse/edbrowse_3.6.0.1-2.dsc

Bug#756630: [Pkg-shadow-devel] Bug#756630: newusers fails adding multiple users

[Serge E. Hallyn]

On Tue, Jun 21, 2016 at 11:42:25AM +0200, Mònica Ramírez Arceda wrote:
> Hi,
> 
> I can confirm this bug. Using a file with 5 new users I get the
> following error:
> 
> # newusers 5users.csv 
> *** Error in `newusers': double free or corruption (!prev): 
> 0x01ae2d10 ***
> Aborted

Could you run that in gdb and show the backtrace here?  It smells like
a bad realloc.

> A curious detail: if the first 4 users are already created and I run
> newusers, the 5th one is added without problems. If I have 6 users in
> the file and the first 5 users are already created the 6th one is added
> without problems. And so on.
> 
> $ dpkg -s passwd | grep 'Version'
> Version: 1:4.2-3.1
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#824391: [Pkg-shadow-devel] Bug#824391: please add ttySAC* to securetty

[Serge E. Hallyn]

On Mon, Jun 06, 2016 at 01:49:39AM +0200, Steinar H. Gunderson wrote:
> On Mon, May 16, 2016 at 03:01:59PM +, Serge Hallyn wrote:
> > Seems reasonable to me.
> 
> I see there hasn't been a maintainer upload of shadow since November 2014
> (there was an NMU November 2015). Does this mean that if I want this for
> stretch, I'll need to NMU?

Or become the new maintainer? :)

Bug#825948: crash with readline and ctrl-d

[Serge E. Hallyn]

Package: edbrowse
Version: 3.6.0.1-1

Hi,

there is a bug in the edbrowse package, which is fixed upstream by commit
543e667e3:  Fix a possible NULL pointer dereference.  It's trivially
reproducible by doing

rl
ctrl-d

Bug#573072: candidate package available

[Serge E. Hallyn]

A new package which builds, installs, and runs on debian unstable
is under http://people.canonical.com/~serge/netcf.  It will do the
ncftool commands 'list', 'ifdown', and 'ifup'.  The 'define' command
claims to succeed, but doesn't actually appear to do anything.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#573072: candidate package available

[Serge E. Hallyn]

Hi,

Daniel Berrange: thanks very much.

I've started a package for Ubuntu and posted it here:
http://people.canonical.com/~serge/netcf-0.1.9-package.tar.gz

I'll spend some time test-building in debian Unstable, but haven't
done so yet.  If someone else wants to take it and run with it,
by all means please feel free but let me know so we don't duplicate
too much effort :)

thanks,
-serge



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#644515: /etc/init.d/xinetd kills LXC container's xinetd

[Serge E. Hallyn]

Package: xinetd
Version: 1:2.3.14-7

At https://bugs.launchpad.net/ubuntu/+source/xinetd/+bug/868538, Ulli
Horlacher reports:

I have an Ubuntu LXC host with several containers running internet
services via xinetd.

Sometimes the container services die without any reason and no logfile
entry. First, I thought LXC is not that stable as I hoped, but now I
found the bug inside /etc/init.d/xinetd !

The problem is: when I stop xinetd on the host with command
/etc/init.d/xinetd stop
this stops all LXC container xinetd processes, too!

/etc/init.d/xinetd contains bad code which does not respect the xinetd
pidfile. See man start-stop-daemon:

  Note: unless --pidfile is specified, start-stop-daemon behaves similar
  to killall(1). start-stop-daemon will scan the process table looking
  for any processes which match the process name (...)

The following patch prevents this unwanted behaviour and let the
container's xinetd untouched:

--- /tmp/xinetd 2011-10-05 18:08:13.0 +0200
+++ xinetd 2011-10-05 18:23:19.0 +0200
@@ -17,7 +17,7 @@
 DAEMON=/usr/sbin/$NAME
 PIDFILE=/var/run/$NAME.pid

-test -x $DAEMON || exit 0
+test -x $DAEMON || exit 0

 test -e /etc/default/$NAME  . /etc/default/$NAME
 case $INETD_COMPAT in
@@ -47,18 +47,20 @@
 start)
 checkportmap
 log_daemon_msg Starting internet superserver $NAME
- start-stop-daemon --start --quiet --background --exec $DAEMON -- \
- -pidfile $PIDFILE $XINETD_OPTS
+ start-stop-daemon --start --pidfile $PIDFILE --quiet --background \
+ --exec $DAEMON -- -pidfile $PIDFILE $XINETD_OPTS
 log_end_msg $?
 ;;
 stop)
 log_daemon_msg Stopping internet superserver $NAME
- start-stop-daemon --stop --signal 3 --quiet --oknodo --exec $DAEMON
+ start-stop-daemon --stop --pidfile $PIDFILE --signal 3 --quiet \
+ --oknodo --exec $DAEMON
 log_end_msg $?
 ;;
 reload)
 log_daemon_msg Reloading internet superserver configuration $NAME
- start-stop-daemon --stop --signal 1 --quiet --oknodo --exec $DAEMON
+ start-stop-daemon --stop --pidfile $PIDFILE --signal 1 --quiet \
+ --oknodo --exec $DAEMON
 log_end_msg $?
 ;;
 restart|force-reload)
@@ -66,7 +68,7 @@
 $0 start
 ;;
 status)
- status_of_proc -p $PIDFILE $DAEMON xinetd  exit 0 || exit $?
+ status_of_proc -p $PIDFILE $DAEMON xinetd  exit 0 || exit $?
;;
 *)
 echo Usage: /etc/init.d/xinetd 
{start|stop|reload|force-reload|restart|status}



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#644457: include libvirtd man page

[Serge E. Hallyn]

Package: libvirt
Version: 0.9.6-1

libvirt ships with a libvirtd.8 man page (daemon/libvirtd.8.in), but
the package is not installing that.  A possible debdiff is below, though
I assume that, in addition, '@sysconfdir@' and '@localstatedir@' should
be switched out?

thanks,
-serge

diff -Nru libvirt-0.9.6/debian/changelog libvirt-0.9.6/debian/changelog
--- libvirt-0.9.6/debian/changelog  2011-09-26 16:28:16.0 -0500
+++ libvirt-0.9.6/debian/changelog  2011-10-05 22:38:33.0 -0500
@@ -1,3 +1,9 @@
+libvirt (0.9.6-2) oneiric; urgency=low
+
+  * Ship the libvirtd.8 manpage.
+
+ -- Serge Hallyn serge.hal...@ubuntu.com  Wed, 05 Oct 2011 22:38:15 -0500
+
 libvirt (0.9.6-1) unstable; urgency=low
 
   * [828e4e3] New upstream version 0.9.6
diff -Nru libvirt-0.9.6/debian/libvirt-bin.manpages 
libvirt-0.9.6/debian/libvirt-bin.manpages
--- libvirt-0.9.6/debian/libvirt-bin.manpages   2011-07-19 15:15:44.0 
-0500
+++ libvirt-0.9.6/debian/libvirt-bin.manpages   2011-10-05 22:35:48.0 
-0500
@@ -1 +1,2 @@
 tools/virsh.1
+daemon/libvirtd.8
diff -Nru libvirt-0.9.6/debian/patches/manpage-fix-libvirtd-conf-path.patch 
libvirt-0.9.6/debian/patches/manpage-fix-libvirtd-conf-path.patch
--- libvirt-0.9.6/debian/patches/manpage-fix-libvirtd-conf-path.patch   
1969-12-31 18:00:00.0 -0600
+++ libvirt-0.9.6/debian/patches/manpage-fix-libvirtd-conf-path.patch   
2011-10-05 22:35:19.0 -0500
@@ -0,0 +1,17 @@
+Index: libvirt-0.9.6/daemon/libvirtd.8.in
+===
+--- libvirt-0.9.6.orig/daemon/libvirtd.8.in2011-10-05 22:34:39.186274182 
-0500
 libvirt-0.9.6/daemon/libvirtd.8.in 2011-10-05 22:35:17.174273540 -0500
+@@ -187,9 +187,9 @@
+ On receipt of \fB\s-1SIGHUP\s0\fR libvirtd will reload its configuration.
+ .SH FILES
+ .IX Header FILES
+-.ie n .IP \fI\fI@sysconfdir\fI@/libvirtd.conf\fR 4
+-.el .IP \fI\f(CI@sysconfdir\fI@/libvirtd.conf\fR 4
+-.IX Item @sysconfdir@/libvirtd.conf
++.ie n .IP \fI\fI@sysconfdir\fI@/libvirt/libvirtd.conf\fR 4
++.el .IP \fI\f(CI@sysconfdir\fI@/libvirt/libvirtd.conf\fR 4
++.IX Item @sysconfdir@/libvirt/libvirtd.conf
+ The default configuration file used by libvirtd, unless overridden on the
+ command line using the \fB\-f\fR|\fB\-\-config\fR option.
+ .ie n .IP \fI\fI@localstatedir\fI@/run/libvirt/libvirt\-sock\fR 4
diff -Nru libvirt-0.9.6/debian/patches/series 
libvirt-0.9.6/debian/patches/series
--- libvirt-0.9.6/debian/patches/series 2011-09-26 16:27:17.0 -0500
+++ libvirt-0.9.6/debian/patches/series 2011-10-05 22:34:33.0 -0500
@@ -10,3 +10,4 @@
 Autodetect-if-the-remote-nc-command-supports-the-q-o.patch
 Disable-failing-virnetsockettest.patch
 debian/Don-t-require-gawk-for-a-simple-print-expression.patch
+manpage-fix-libvirtd-conf-path.patch



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#631134: Setting capabilities on large files

[Serge E. Hallyn]

Package: libcap2
Version: 1:2.21-1

Setting capabilies on large files on i386 fails.  A fix for
this has been pushed to the upstream libcap git tree, with no
new version number.  Could this fix be pulled into the debian
package?

The relevant Ubuntu bug is 
https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/794202

Here is a proposed debdiff.

thanks,
-serge

diff -Nru libcap2-2.21/debian/changelog libcap2-2.21/debian/changelog
--- libcap2-2.21/debian/changelog   2011-05-22 13:23:51.0 -0500
+++ libcap2-2.21/debian/changelog   2011-06-20 11:46:50.0 -0500
@@ -1,3 +1,11 @@
+libcap2 (1:2.21-2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * 0002-support-getting-setting-capabilities-on-large-files.patch:
+patch from upstream to enable setting capabilities on large files.
+
+ -- Serge Hallyn serge.hal...@ubuntu.com  Mon, 20 Jun 2011 11:44:43 -0500
+
 libcap2 (1:2.21-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru 
libcap2-2.21/debian/patches/0002-support-getting-setting-capabilities-on-large-files.patch
 
libcap2-2.21/debian/patches/0002-support-getting-setting-capabilities-on-large-files.patch
--- 
libcap2-2.21/debian/patches/0002-support-getting-setting-capabilities-on-large-files.patch
  1969-12-31 18:00:00.0 -0600
+++ 
libcap2-2.21/debian/patches/0002-support-getting-setting-capabilities-on-large-files.patch
  2011-06-20 11:43:59.0 -0500
@@ -0,0 +1,32 @@
+From f464aa7fd9b5953c8ddc83450f37c00bf62ac1f2 Mon Sep 17 00:00:00 2001
+From: Andrew G. Morgan mor...@kernel.org
+Date: Sun, 12 Jun 2011 18:44:37 -0700
+Subject: [PATCH 1/1] Support getting/setting capabilities on large files.
+
+See:
+  https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/794202
+
+Patch originally from Mikhail Kulinich, but forwarded from Serge Hallyn
+at Canonical.
+
+Signed-off-by: Andrew G. Morgan mor...@kernel.org
+---
+ Make.Rules |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/Make.Rules b/Make.Rules
+index 2563e82..b99b752 100644
+--- a/Make.Rules
 b/Make.Rules
+@@ -48,7 +48,7 @@ KERNEL_HEADERS := $(topdir)/libcap/include
+ IPATH += -fPIC -I$(topdir)/libcap/include -I$(KERNEL_HEADERS)
+ 
+ CC := gcc
+-CFLAGS := -O2
++CFLAGS := -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
+ BUILD_CC := $(CC)
+ BUILD_CFLAGS := $(CFLAGS) $(IPATH)
+ AR := ar
+-- 
+1.7.5.4
+
diff -Nru libcap2-2.21/debian/patches/series libcap2-2.21/debian/patches/series
--- libcap2-2.21/debian/patches/series  2011-05-22 13:22:10.0 -0500
+++ libcap2-2.21/debian/patches/series  2011-06-20 11:44:37.0 -0500
@@ -1 +1,2 @@
 0001-fix-Makefiles.patch
+0002-support-getting-setting-capabilities-on-large-files.patch



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#629804: fix ipsec-tools FTBFS

[Serge E. Hallyn]

Package: ipsec-tools
Version: 1:0.8.0-3.1

Hi,

gcc has changed its behavior so that it now returns error when it sees
unknown flags.  configure was passing -R to gcc at times and counting
on this behavior to ignore -R.  Now it must pass -Wl,-R.  With this
debdiff, ipsec-tools compiles for me in sid.

thanks,
-serge

diff -Nru ipsec-tools-0.8.0/debian/changelog ipsec-tools-0.8.0/debian/changelog
--- ipsec-tools-0.8.0/debian/changelog  2011-03-25 06:32:19.0 -0500
+++ ipsec-tools-0.8.0/debian/changelog  2011-06-08 10:28:50.0 -0500
@@ -1,3 +1,10 @@
+ipsec-tools (1:0.8.0-3.1) unstable; urgency=low
+
+  * fix configure to not pass -R without -Wl,-R 
+
+ -- Serge Hallyn se...@debian.hallyn.com  Wed, 08 Jun 2011 10:28:36 -0500
+
 ipsec-tools (1:0.8.0-3) unstable; urgency=low
 
   * Apply patch from Mats Erik Andersson to fix build problems on *BSD
diff -Nru ipsec-tools-0.8.0/debian/patches/configure-pass-Wl-with-R.patch 
ipsec-tools-0.8.0/debian/patches/configure-pass-Wl-with-R.patch
--- ipsec-tools-0.8.0/debian/patches/configure-pass-Wl-with-R.patch 
1969-12-31 18:00:00.0 -0600
+++ ipsec-tools-0.8.0/debian/patches/configure-pass-Wl-with-R.patch 
2011-06-08 10:28:13.0 -0500
@@ -0,0 +1,104 @@
+Description: Always pass -Wl,-Rxyz rather than just -Rxyz
+ gcc used to return 0 on unknown flags, but now returns an error.  So
+ test compilations fail because we are passing -R/lib.
+Author: Serge Hallyn serge.hal...@ubuntu.com
+Origin: serge.hal...@ubuntu.com
+Forwarded: no
+Last-Update: 2011-06-08
+
+--- ipsec-tools-0.8.0.orig/configure
 ipsec-tools-0.8.0/configure
+@@ -13076,7 +13076,7 @@ fi
+   as_fn_error $? ICONV libs or includes not found. 
Aborting. $LINENO 5
+   fi
+   fi
+-  LIBS=$LIBS -L$libiconv_dir/lib -R$libiconv_dir/lib -liconv
++  LIBS=$LIBS -L$libiconv_dir/lib -Wl,-R$libiconv_dir/lib -liconv
+   for ac_func in iconv_open
+ do :
+   ac_fn_c_check_func $LINENO iconv_open ac_cv_func_iconv_open
+@@ -1,7 +1,7 @@ fi
+ 
+ $as_echo #define HAVE_LIBRADIUS /**/ confdefs.h
+ 
+-  LIBS=$LIBS -L$libradius_dir/lib -R$libradius_dir/lib -lradius
++  LIBS=$LIBS -L$libradius_dir/lib -Wl,-R$libradius_dir/lib -lradius
+   for ac_func in rad_create_request
+ do :
+   ac_fn_c_check_func $LINENO rad_create_request 
ac_cv_func_rad_create_request
+@@ -13536,7 +13536,7 @@ fi
+ 
+ $as_echo #define HAVE_LIBPAM /**/ confdefs.h
+ 
+-  LIBS=$LIBS -L$libpam_dir/lib -R$libpam_dir/lib -lpam
++  LIBS=$LIBS -L$libpam_dir/lib -Wl,-R$libpam_dir/lib -lpam
+   for ac_func in pam_start
+ do :
+   ac_fn_c_check_func $LINENO pam_start ac_cv_func_pam_start
+@@ -13739,7 +13739,7 @@ fi
+ 
+ $as_echo #define HAVE_LIBLDAP /**/ confdefs.h
+ 
+-  LIBS=$LIBS -L$libldap_dir/lib -R$libldap_dir/lib -lldap
++  LIBS=$LIBS -L$libldap_dir/lib -Wl,-R$libldap_dir/lib -lldap
+ 
+   saved_CFLAGS=$CFLAGS
+   CFLAGS=$CFLAGS -Wall -Werror
+--- ipsec-tools-0.8.0.orig/configure.ac
 ipsec-tools-0.8.0/configure.ac
+@@ -318,7 +318,7 @@ if test $libiconv_dir != no; then
+   AC_MSG_ERROR([ICONV libs or includes not found. 
Aborting.])
+   fi
+   fi
+-  LIBS=$LIBS -L$libiconv_dir/lib -R$libiconv_dir/lib -liconv
++  LIBS=$LIBS -L$libiconv_dir/lib -Wl,-R$libiconv_dir/lib -liconv
+   AC_CHECK_FUNCS(iconv_open)
+ fi
+ 
+@@ -382,7 +382,7 @@ if test $libradius_dir != no; then
+   fi
+   fi
+   AC_DEFINE([HAVE_LIBRADIUS], [], [Hybrid authentication uses RADIUS])
+-  LIBS=$LIBS -L$libradius_dir/lib -R$libradius_dir/lib -lradius
++  LIBS=$LIBS -L$libradius_dir/lib -Wl,-R$libradius_dir/lib -lradius
+   AC_CHECK_FUNCS(rad_create_request)
+ fi
+ 
+@@ -408,7 +408,7 @@ if test $libpam_dir != no; then
+   fi
+   fi
+   AC_DEFINE([HAVE_LIBPAM], [], [Hybrid authentication uses PAM])
+-  LIBS=$LIBS -L$libpam_dir/lib -R$libpam_dir/lib -lpam
++  LIBS=$LIBS -L$libpam_dir/lib -Wl,-R$libpam_dir/lib -lpam
+   AC_CHECK_FUNCS(pam_start)
+ fi
+ 
+@@ -434,7 +434,7 @@ if test $libldap_dir != no; then
+   fi
+   fi
+   AC_DEFINE([HAVE_LIBLDAP], [], [Hybrid authentication uses LDAP])
+-  LIBS=$LIBS -L$libldap_dir/lib -R$libldap_dir/lib -lldap
++  LIBS=$LIBS -L$libldap_dir/lib -Wl,-R$libldap_dir/lib -lldap
+ 
+   saved_CFLAGS=$CFLAGS
+   CFLAGS=$CFLAGS -Wall -Werror
+--- ipsec-tools-0.8.0.orig/aclocal.m4
 ipsec-tools-0.8.0/aclocal.m4
+@@ -5994,7 +5994,7 @@ if test $_lt_caught_CXX_error != yes;
+ _LT_TAGVAR(no_undefined_flag, $1)=' -zdefs'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} 
-h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects 
$compiler_flags'
+ _LT_TAGVAR(archive_expsym_cmds, $1)='$CC 
-G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs 
$postdep_objects $compiler_flags ${wl}-retain-symbols-file 

Bug#629828: LSB-ify ipsec init scripts

[Serge E. Hallyn]

Package: ipsec-tools
Version: 1:0.8.0-3

Ubuntu patches setkey.init and racoon.init to use the lsb functions, as
below.  Could these patches be applied in the debian package?

thanks,
-serge

diff -Nru ipsec-tools-0.8.0/debian/ipsec-tools.setkey.init 
ipsec-tools-0.8.0/debian/ipsec-tools.setkey.init
--- ipsec-tools-0.8.0/debian/ipsec-tools.setkey.init2011-03-25 
06:32:19.0 -0500
+++ ipsec-tools-0.8.0/debian/ipsec-tools.setkey.init2011-06-08 
12:23:25.0 -0500
@@ -28,23 +28,27 @@
 
 set -e
 
+. /lib/lsb/init-functions
+
 case $1 in
   start)
-   echo Loading IPsec SA/SP database: 
-
+   log_begin_msg Loading IPsec SA/SP database: 
+   err=0
for file in $SETKEY_CONF $SETKEY_CONF_DIR/*.conf ; do
if [ -r $file ] ; then
-   echo  - ${file}
-   $SETKEY -f $file
+   log_progress_msg  - ${file}
+   $SETKEY -f $file || err=1
fi
done
-   echo done.
+   log_end_msg $err
;;
   stop)
-   echo -n Flushing IPsec SA/SP database: 
-   $SETKEY -F 
-   $SETKEY -FP
-   echo done.
+   log_begin_msg Flushing IPsec SA/SP database: 
+
+   err=0
+   $SETKEY -F || err=1
+   $SETKEY -FP || err=1
+   log_end_msg $err
;;
   restart|force-reload)
$0 stop
@@ -53,7 +57,7 @@
;;
   *)
N=/etc/init.d/$NAME
-   echo Usage: $N {start|stop|restart|force-reload} 2
+   log_success_msg Usage: $N {start|stop|restart|force-reload} 2
exit 1
;;
 esac

diff -Nru ipsec-tools-0.8.0/debian/racoon.init 
ipsec-tools-0.8.0/debian/racoon.init
--- ipsec-tools-0.8.0/debian/racoon.init2011-03-25 06:32:19.0 
-0500
+++ ipsec-tools-0.8.0/debian/racoon.init2011-06-08 12:34:43.0 
-0500
@@ -71,6 +71,8 @@
fi
 fi
 
+. /lib/lsb/init-functions
+
 case  $CONFIG_MODE in
   racoon-tool)
   # /usr/sbin/racoon-tool command complies with Debian Policy so just do this:
@@ -87,17 +89,19 @@
   *)
case $1 in
   start)
-echo -n Starting IKE (ISAKMP/Oakley) server: racoon
-   start-stop-daemon --start --quiet --exec ${DAEMON} -- 
${RACOON_ARGS}
-   echo .
+log_begin_msg Starting IKE (ISAKMP/Oakley) server: racoon
+   err=0
+   start-stop-daemon --start --quiet --exec ${DAEMON} -- 
${RACOON_ARGS} || err=1
+   log_end_msg $err
 ;;
  
  stop)
-   echo -n Stopping IKE (ISAKMP/Oakley) server: racoon
+   log_begin_msg Stopping IKE (ISAKMP/Oakley) server: racoon
+   err=0
 start-stop-daemon --stop --retry 25 --quiet --oknodo \
---pidfile $PID_FILE --name racoon
+--pidfile $PID_FILE --name racoon || err=1
 rm -f $PID_FILE /var/run/racoon/racoon.sock
-   echo .
+   log_end_msg $err
;;
  
  reload|force-reload)
@@ -112,7 +116,7 @@
 
  
   *)
-echo Usage: $0 {start|stop|reload|force-reload|restart} 2
+log_success_msg Usage: $0 
{start|stop|reload|force-reload|restart} 2
exit 1
esac
;;



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#627636: lxc: New upstream release (0.7.4)

[Serge E. Hallyn]

Package: lxc
Severity: wishlist

Hi,

please update to 0.7.4 or 0.7.4.2.  A package based on 0.7.4.2 is at
http://people.canonical.com/~serge/lxc_0.7.4.2-1-package.tar.gz

thanks,
-serge



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#573072: any work in progress?

[Serge E. Hallyn]

Hi,

to reduce the chances of conflicting parallel efforts, is anyone
currently privately working on implementing the needed support?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#591410: Info received (bug 591410 regression)

[Serge E. Hallyn]

The following debdiff fixes it for me:

diff -Nru libcap2-2.20/debian/changelog libcap2-2.20/debian/changelog
--- libcap2-2.20/debian/changelog   2011-02-11 13:40:48.0 -0600
+++ libcap2-2.20/debian/changelog   2011-05-10 10:21:37.0 -0500
@@ -1,3 +1,10 @@
+libcap2 (1:2.20-1ubuntu1) oneiric; urgency=low
+
+  * debian/patches/0001-fix-Makefiles.patch: link pam_cap against -lpam.
+(LP: #582769)
+
+ -- Serge Hallyn serge.hal...@ubuntu.com  Tue, 10 May 2011 10:18:58 -0500
+
 libcap2 (1:2.20-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru libcap2-2.20/debian/patches/0001-fix-Makefiles.patch 
libcap2-2.20/debian/patches/0001-fix-Makefiles.patch
--- libcap2-2.20/debian/patches/0001-fix-Makefiles.patch1969-12-31 
18:00:00.0 -0600
+++ libcap2-2.20/debian/patches/0001-fix-Makefiles.patch2011-05-10 
10:18:45.0 -0500
@@ -0,0 +1,22 @@
+Description: compile pam_cap with -lpam
+ A similar fix was in Debian but appears to have been accidentally
+ dropped.  Drop this one if or when debian gets it back so we can
+ directly sync.
+Author: Andrew Straw straw...@astraw.com
+Forwarded: no
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/582769
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591410
+
+Index: libcap2-2.20/pam_cap/Makefile
+===
+--- libcap2-2.20.orig/pam_cap/Makefile 2011-05-10 10:15:02.540359338 -0500
 libcap2-2.20/pam_cap/Makefile  2011-05-10 10:15:07.600359338 -0500
+@@ -7,7 +7,7 @@
+ # that this next line does *not* require -lpam on it.) If you think it
+ # does, *verify that it does*, and if you observe that it fails as
+ # written (and you know why it fails), email me and explain why. Thanks!
+-LDLIBS += -L../libcap -lcap
++LDLIBS += -L../libcap -lcap -lpam
+ 
+ all: pam_cap.so
+   $(MAKE) testcompile
diff -Nru libcap2-2.20/debian/patches/series libcap2-2.20/debian/patches/series
--- libcap2-2.20/debian/patches/series  1969-12-31 18:00:00.0 -0600
+++ libcap2-2.20/debian/patches/series  2011-05-10 10:14:56.0 -0500
@@ -0,0 +1 @@
+0001-fix-Makefiles.patch



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#591410: bug 591410 regression

[Serge E. Hallyn]

The fix for bug 591410 appears to be have been dropped from
libcap2 1:2.20-1, which gives me:

May  8 22:51:08 debian authdaemond: PAM unable to 
dlopen(/lib/security/pam_cap.so): /lib/security/pam_cap.so: undefined symbol: 
pam_get_item
May  8 22:51:08 debian authdaemond: PAM adding faulty module: 
/lib/security/pam_cap.so
May  8 22:51:08 debian authdaemond: pam_unix(imap:auth): authentication 
failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=serge

In fact, -lpam is no longer being added to pam_cap's LDLIBS.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#608933: Teach resolvconf that bind9 uses /var/run/named

[Serge E. Hallyn]

Package: resolvconf
Version: 1.47

The bind9 package uses /var/run/named, but the resolvconf
package thinks it uses /var/run/bind.  Below is a trivial
debdiff to hopefully fix this.

diff -Nru resolvconf-1.47/debian/changelog 
resolvconf-1.47fixbind/debian/changelog
--- resolvconf-1.47/debian/changelog2010-12-01 09:22:01.0 -0600
+++ resolvconf-1.47fixbind/debian/changelog 2011-01-04 12:12:40.0 
-0600
@@ -1,3 +1,10 @@
+resolvconf (1.47fixbind) unstable; urgency=low
+
+  * The bind9 package uses /var/run/named, not /var/run/bind.
+(See https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/693002)
+
+ -- Serge Hallyn serge.hal...@ubuntu.com  Tue, 04 Jan 2011 12:07:12 -0600
+
 resolvconf (1.47) unstable; urgency=low
 
   [ Thomas Hood ]
diff -Nru resolvconf-1.47/etc/resolvconf/update.d/bind 
resolvconf-1.47fixbind/etc/resolvconf/update.d/bind
--- resolvconf-1.47/etc/resolvconf/update.d/bind2006-08-09 
08:36:43.0 -0500
+++ resolvconf-1.47fixbind/etc/resolvconf/update.d/bind 2011-01-04 
12:07:10.0 -0600
@@ -21,7 +21,7 @@
 [ -f /etc/bind/named.conf.options ] || exit 0
 
 OPTS_FILE=named.options
-RUN_DIR=/var/run/bind
+RUN_DIR=/var/run/named
 
 [ -d $RUN_DIR ] || mkdir --parents --mode=0755 $RUN_DIR
 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#603944: Updated patch

[Serge E. Hallyn]

Here is a patch (against the ubuntu package, just as example)
which instead of doing a dumb retry loop, waits for udev.

=== modified file 'debian/changelog'
--- debian/changelog2010-04-26 15:17:47 +
+++ debian/changelog2010-12-08 21:44:32 +
@@ -1,3 +1,15 @@
+initramfs-tools (0.92bubuntu79) natty; urgency=low
+
+  * When using multipath, it is possible that mountroot() will race
+with udev's renaming of /dev/disk/by-uuid/{rootfs-uuid} from
+/dev/sd?? to /dev/mapper/something.  After multipath has grabbed
+the /dev/sd?? and until udev completes the rename, mounting
+/dev/disk/by-uuid/{rootfs-uuid} will fail with -EBUSY.  In that
+case, call 'udevsettle' to wait until udev has finished all its
+related actions. (Closes LP: #686832)
+
+ -- Serge Hallyn serge.hal...@ubuntu.com  Fri, 19 Nov 2010 12:19:43 -0600
+
 initramfs-tools (0.92bubuntu78) lucid; urgency=low
 
   * hooks/compcache: Escape $-expansions inside EOF (thanks, Eugene San;

=== modified file 'scripts/local'
--- scripts/local   2009-12-21 23:06:53 +
+++ scripts/local   2010-11-20 01:03:26 +
@@ -69,10 +69,19 @@
# FIXME This has no error checking
[ -n ${FSTYPE} ]  modprobe ${FSTYPE}
 
-   # FIXME This has no error checking
# Mount root
-   mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
-   mountroot_status=$?
+   tries=0
+   ret=1
+   while [ $tries -lt 2 -a $ret -ne 0 ]; do
+   mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} 
${rootmnt}
+   ret=$?
+   if [ $ret -ne 0 ]; then
+   echo failed attempt $tries to mount $ROOT as root
+   udevadm settle
+   tries=$((tries+1))
+   fi
+   done
+   mountroot_status=$ret
if [ $LOOP ]; then
if [ $mountroot_status != 0 ]; then
if [ ${FSTYPE} = ntfs ] || [ ${FSTYPE} = vfat ]; then




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#603944: retry mounting of root

[Serge E. Hallyn]

Package: initramfs-tools
Version: 0.98

When using multipath, it is possible that mountroot() will race with
udev's renaming of /dev/disk/by-uuid/{rootfs-uuid} from /dev/sd?? to
/dev/mapper/something.  After multipath has grabbed the /dev/sd?? and
until udev completes the rename, mounting
/dev/disk/by-uuid/{rootfs-uuid} will fail with -EBUSY.

Here is a patch I've been using successfully for awhile.  Colin Watson
has suggested that:

 A poll/retry loop is generally a suboptimal way to do this kind of
 thing; what we really want is to wait for udev to tell us that it has
 finished with the event that triggered renaming of the device.

which does seem cleaner.

thanks,
-serge

diff -Nru initramfs-tools-0.98ubuntu2/debian/changelog 
initramfs-tools-0.98ubuntu3/debian/changelog
--- initramfs-tools-0.98ubuntu2/debian/changelog2010-08-20 
03:48:58.0 -0500
+++ initramfs-tools-0.98ubuntu3/debian/changelog2010-08-24 
22:31:31.0 -0500
@@ -1,3 +1,14 @@
+initramfs-tools (0.98ubuntu3) maverick; urgency=low
+
+  * Add retries to mountroot().  This is particularly needed when we
+use multipath, because it is possible that mountroot() will race
+with udev's renaming of /dev/disk/by-uuid/{rootfs-uuid} from
+/dev/sd?? to /dev/mapper/something.  After multipath has grabbed
+the /dev/sd?? and until udev completes the rename, mounting
+/dev/disk/by-uuid/{rootfs-uuid} will fail with -EBUSY.
+
+ -- Serge Hallyn serge.hal...@canonical.com  Tue, 24 Aug 2010 22:17:57 -0500
+
 initramfs-tools (0.98ubuntu2) maverick; urgency=low
 
   * The ramzswap device changed its interface so that the disk size needs to
diff -Nru initramfs-tools-0.98ubuntu2/scripts/local 
initramfs-tools-0.98ubuntu3/scripts/local
--- initramfs-tools-0.98ubuntu2/scripts/local   2010-08-20 03:48:58.0 
-0500
+++ initramfs-tools-0.98ubuntu3/scripts/local   2010-08-24 22:16:17.0 
-0500
@@ -86,10 +86,19 @@
# FIXME This has no error checking
[ -n ${FSTYPE} ]  modprobe ${FSTYPE}
 
-   # FIXME This has no error checking
# Mount root
-   mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
-   mountroot_status=$?
+   tries=0
+   ret=1
+   while [ $tries -lt 10 -a $ret -ne 0 ]; do
+   mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} 
${rootmnt}
+   ret=$?
+   if [ $ret -ne 0 ]; then
+   echo failed attempt $tries to mount $ROOT as root
+   sleep 1
+   tries=$((tries+1))
+   fi
+   done
+   mountroot_status=$ret
if [ $LOOP ]; then
if [ $mountroot_status != 0 ]; then
if [ ${FSTYPE} = ntfs ] || [ ${FSTYPE} = vfat ]; then



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org