Debian Bug report logs - #833256
util-linux: Please use login/passwd implementations provided by util-linux

Reply or subscribe to this bug.

Toggle useless messages

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

From: Laurent Bigonville <bigon@debian.org>

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

Subject: util-linux: Please use login/su/... implementations provided by util-linux

Date: Tue, 02 Aug 2016 11:01:56 +0200

Package: util-linux
Version: 2.28-6
Severity: normal

Hi,

ATM, on debian, login, su, ... are provided by the shadow package.

It seems that all other distribution are using the implementations from
util-linux.

Shouldn't debian do the same and shouldn't we build the "login" from
util-linux?

This should of course be coordinated with the maintainer of the shadow
package.

Regards,

Laurent Bigonville

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages util-linux depends on:
ii  libblkid1      2.28-6
ii  libc6          2.23-4
ii  libfdisk1      2.28-6
ii  libmount1      2.28-6
ii  libncursesw5   6.0+20160625-1
ii  libpam0g       1.1.8-3.3
ii  libselinux1    2.5-3
ii  libsmartcols1  2.28-6
ii  libsystemd0    231-1
ii  libtinfo5      6.0+20160625-1
ii  libudev1       231-1
ii  libuuid1       2.28-6
ii  zlib1g         1:1.2.8.dfsg-2+b1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools          4.0-2
ii  kbd                 2.0.3-2
ii  util-linux-locales  2.28-6

-- no debconf information

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

From: Andreas Henriksson <andreas@fatal.se>

To: Laurent Bigonville <bigon@debian.org>, 833256@bugs.debian.org

Subject: Re: Bug#833256: util-linux: Please use login/su/... implementations provided by util-linux

Date: Tue, 2 Aug 2016 11:45:40 +0200

Hello Laurent Bigonville.

Thanks for opening this bug report. I remember we've touched on this
subject inside another bug report but I feel it's useful to have a
separate on-topic discussion about this...

On Tue, Aug 02, 2016 at 11:01:56AM +0200, Laurent Bigonville wrote:
> Package: util-linux
> Version: 2.28-6
> Severity: normal
> 
> Hi,
> 
> ATM, on debian, login, su, ... are provided by the shadow package.

Currently we use the --disable-login --disable-nologin and
--disable-su configure flags when building util-linux in Debian
because these are provided by the "login" package.

We also use --disable-chfn-chsh as that's provided by the "passwd"
package.

Both "login" and "passwd" are built from src:shadow.

> 
> It seems that all other distribution are using the implementations from
> util-linux.

Yes.

> 
> Shouldn't debian do the same and shouldn't we build the "login" from
> util-linux?

It's not only these tools, but the entile login and authentication stack
seems to have a different origin in Debian compared to other
distributions. I'm sure you for example know better than me about the
history about our PAM deviations from other distributions.
I think this issue should be viewed in a broader perspective.

> 
> This should of course be coordinated with the maintainer of the shadow
> package.

Feedback from the shadow maintainer(s) would be very welcome/useful
on this bug report.

I think we should not only focus about a few tools that overlap between
shadow and util-linux, but view this from a bigger perspective. Someone
needs to draw the bigger picture, come up with a plan for how we'd like
the future map to look like (and why we should do all this work).

Also someone needs to make sure the different implementation of the
tools are actually 100% compatible or what migrations we need to handle
on package upgrades.

Please note that while "login" is Essential: yes, the "passwd" package
is not. Things to keep in mind when expanding util-linux is that
all tools then become Essential: yes which I think is unfortunate as
we should strive to keep the essential set as small as possible.
A package split is probably needed here and that's always hairy to
come up with the right plan that will fit the future developments.
Likely revamping the existing package split would be useful while
at it.

(Some kind of history lesson on why we deviated would likely also be
useful. My limited software archeology experince has taught me that
it's often a very good way to detect and fix problems before introducing
them when doing these kind of switchovers. The devil is often in the 
details. Those details can often be found when seeking the answers to
questions like: Was there a fork or where things developed completely
separately? Why where things developed separately? What are the main
philosophical differences between the development groups? etc...)

I have no personal objections to moving to the util-linux implementation
as they're actively maintained upstream, but I'm not going to actively
work on this myself.
I'm thus tempted to tag this bug report as wontfix for now until
someone lays out information on the "why" and the "how" and hopefully
the interest is also high enough that someone provides a tested patch.
(If you think it sounds like you doing this work means you risk ending
up co-maintaining util-linux in Debian, then yes! New co-maintainers
welcome/needed.)

Regards,
Andreas Henriksson

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

From: Balint Reczey <balint@balintreczey.hu>

To: 833256@bugs.debian.org

Cc: Laurent Bigonville <bigon@debian.org>, Andreas Henriksson <andreas@fatal.se>

Subject: Re: Bug#833256: util-linux: Please use login/su/... implementations provided by util-linux

Date: Fri, 6 Jan 2017 18:29:21 +0100

Hi,

On Tue, 2 Aug 2016 11:45:40 +0200 Andreas Henriksson <andreas@fatal.se>
wrote:
> Hello Laurent Bigonville.
> 
> Thanks for opening this bug report. I remember we've touched on this
> subject inside another bug report but I feel it's useful to have a
> separate on-topic discussion about this...
> 
> On Tue, Aug 02, 2016 at 11:01:56AM +0200, Laurent Bigonville wrote:
> > Package: util-linux
> > Version: 2.28-6
> > Severity: normal
> > 
> > Hi,
> > 
> > ATM, on debian, login, su, ... are provided by the shadow package.
> 
> Currently we use the --disable-login --disable-nologin and
> --disable-su configure flags when building util-linux in Debian
> because these are provided by the "login" package.
> 
> We also use --disable-chfn-chsh as that's provided by the "passwd"
> package.
> 
> Both "login" and "passwd" are built from src:shadow.
> 
> > 
> > It seems that all other distribution are using the implementations from
> > util-linux.
> 
> Yes.
> 
> > 
> > Shouldn't debian do the same and shouldn't we build the "login" from
> > util-linux?
> 
> It's not only these tools, but the entile login and authentication stack
> seems to have a different origin in Debian compared to other
> distributions. I'm sure you for example know better than me about the
> history about our PAM deviations from other distributions.
> I think this issue should be viewed in a broader perspective.
> 
> > 
> > This should of course be coordinated with the maintainer of the shadow
> > package.
> 
> Feedback from the shadow maintainer(s) would be very welcome/useful
> on this bug report.

I have just stepped up as a new shadow maintainer and I would support
the switch to the more widely used variants.

> 
> I think we should not only focus about a few tools that overlap between
> shadow and util-linux, but view this from a bigger perspective. Someone
> needs to draw the bigger picture, come up with a plan for how we'd like
> the future map to look like (and why we should do all this work).

Maybe discussing the bigger picture on
pkg-auth-maintainers@lists.alioth.debian.org would help the planning.

> 
> Also someone needs to make sure the different implementation of the
> tools are actually 100% compatible or what migrations we need to handle
> on package upgrades.
> 
> Please note that while "login" is Essential: yes, the "passwd" package
> is not. Things to keep in mind when expanding util-linux is that
> all tools then become Essential: yes which I think is unfortunate as
> we should strive to keep the essential set as small as possible.

Rebootstrapping [1] already covers util-linux thus I think building
login from util-linux would not cause big problems.

Cheers,
Balint

[1] https://anonscm.debian.org/cgit/users/helmutg/rebootstrap.git/

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

From: Andreas Henriksson <andreas@fatal.se>

To: Balint Reczey <balint@balintreczey.hu>

Cc: 833256@bugs.debian.org, Laurent Bigonville <bigon@debian.org>, pkg-auth-maintainers@lists.alioth.debian.org

Subject: Re: Bug#833256: util-linux: Please use login/su/... implementations provided by util-linux

Date: Fri, 6 Jan 2017 19:49:59 +0100

Hello Balint Reczey,

On Fri, Jan 06, 2017 at 06:29:21PM +0100, Balint Reczey wrote:
> 
> Hi,
> 
> On Tue, 2 Aug 2016 11:45:40 +0200 Andreas Henriksson <andreas@fatal.se>
> wrote:
> > On Tue, Aug 02, 2016 at 11:01:56AM +0200, Laurent Bigonville wrote:
> > > Hi,
> > > 
> > > ATM, on debian, login, su, ... are provided by the shadow package.
> > 
> > Currently we use the --disable-login --disable-nologin and
> > --disable-su configure flags when building util-linux in Debian
> > because these are provided by the "login" package.
> > 
> > We also use --disable-chfn-chsh as that's provided by the "passwd"
> > package.
> > 
> > Both "login" and "passwd" are built from src:shadow.
[...]
> I have just stepped up as a new shadow maintainer and I would support
> the switch to the more widely used variants.

Awesome both that you're stepping up a a new maintainer and that you're
interested in discussing this topic. I have to confess that I'm quite
ignorant about login tools. Please educate me. ;)

If you do support moving to util-linux tools, then are you looking to
get rid of src:shadow completely as a long-term plan or how do you view
what role it'll play in the future?

Just yesterday I discussed about various bit being part of a debootstrap
--variant=minbase in Debian (smallest possible debootstrappable system)
and login came up as something questionable for the smallest possible
system (think init-less container).
The explanation that was mentioned was that login package shipped 'su'.

Maybe we should split up this discussion in multiple tiers, where tier1
could be just about u-l taking over su and allowing login package to
become non-essential and priority important?
The tier2 discussion could be about other login package utils like
login, nologin, newgrp. Note that u-l does not provide replacement tools
for faillog, lastlog, sg. How do we handle these? Are they still
relevant?
The tier3 discussion might be about some passwd tools, for example these
are also provided by u-l: chfn, chsh. (Note: there are many other tools
in src:shadow passwd package that are not part of u-l.)
Maybe after that we could consider if Priority: required is the correct
one for passwd package (required means it's part of --variant=minbase
where I think it's questionable if it's always needed. Also libuuid1
currently depending on passwd will need to be revisited. We should
be able to drop the old migration code from libuuid1 maintainer
scripts and drop the dependency.)

What do you think about the specific tools and packages?
Which ones specifically would you like to see provided by
util-linux instead (or if others which one?) and why?


(Goes without saying, but ofcourse any of these plans are
at this point targeted for Buster development cycle.)


[...]
> Maybe discussing the bigger picture on
> pkg-auth-maintainers@lists.alioth.debian.org would help the planning.

Sure, added to CC for now. Lets drop the bug report if we drift
too far off-topic for it.

> 
> > 
> > Also someone needs to make sure the different implementation of the
> > tools are actually 100% compatible or what migrations we need to handle
> > on package upgrades.
> > 
> > Please note that while "login" is Essential: yes, the "passwd" package
> > is not. Things to keep in mind when expanding util-linux is that
> > all tools then become Essential: yes which I think is unfortunate as
> > we should strive to keep the essential set as small as possible.
> 
> Rebootstrapping [1] already covers util-linux thus I think building
> login from util-linux would not cause big problems.
> 
> Cheers,
> Balint
> 
> [1] https://anonscm.debian.org/cgit/users/helmutg/rebootstrap.git/

Regards,
Andreas Henriksson

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

From: Bálint Réczey <balint@balintreczey.hu>

To: Andreas Henriksson <andreas@fatal.se>

Cc: 833256@bugs.debian.org, Laurent Bigonville <bigon@debian.org>, pkg-auth-maintainers@lists.alioth.debian.org

Subject: Re: Bug#833256: util-linux: Please use login/su/... implementations provided by util-linux

Date: Mon, 9 Jan 2017 16:07:37 +0100

Hi Andreas,

2017-01-06 19:49 GMT+01:00 Andreas Henriksson <andreas@fatal.se>:
> Hello Balint Reczey,
>
> On Fri, Jan 06, 2017 at 06:29:21PM +0100, Balint Reczey wrote:
>>
>> Hi,
>>
>> On Tue, 2 Aug 2016 11:45:40 +0200 Andreas Henriksson <andreas@fatal.se>
>> wrote:
>> > On Tue, Aug 02, 2016 at 11:01:56AM +0200, Laurent Bigonville wrote:
>> > > Hi,
>> > >
>> > > ATM, on debian, login, su, ... are provided by the shadow package.
>> >
>> > Currently we use the --disable-login --disable-nologin and
>> > --disable-su configure flags when building util-linux in Debian
>> > because these are provided by the "login" package.
>> >
>> > We also use --disable-chfn-chsh as that's provided by the "passwd"
>> > package.
>> >
>> > Both "login" and "passwd" are built from src:shadow.
> [...]
>> I have just stepped up as a new shadow maintainer and I would support
>> the switch to the more widely used variants.
>
> Awesome both that you're stepping up a a new maintainer and that you're
> interested in discussing this topic. I have to confess that I'm quite
> ignorant about login tools. Please educate me. ;)

I have just started maintaining shadow and I still have to get familiar with it
thus I can't provide much education. :-)
I just wanted to assure you about cooperation on my side.

>
> If you do support moving to util-linux tools, then are you looking to
> get rid of src:shadow completely as a long-term plan or how do you view
> what role it'll play in the future?

It is too early for me to sketch up long-term plans but when we reach
the point where nothing useful can be provided by the shadow package
it can go.

>
> Just yesterday I discussed about various bit being part of a debootstrap
> --variant=minbase in Debian (smallest possible debootstrappable system)
> and login came up as something questionable for the smallest possible
> system (think init-less container).
> The explanation that was mentioned was that login package shipped 'su'.
>
> Maybe we should split up this discussion in multiple tiers, where tier1
> could be just about u-l taking over su and allowing login package to
> become non-essential and priority important?

I would prefer u-l taking over all affected commands in one shot
because this is easier to follow.

> The tier2 discussion could be about other login package utils like
> login, nologin, newgrp. Note that u-l does not provide replacement tools
> for faillog, lastlog, sg. How do we handle these? Are they still
> relevant?

A quick test on a sid system showed that lastlog still works while
faillog does not thus I need to check those commands one by one.
Probably all of the commands work with sysv thus my first hunch is
that
they will still be provided by shadow.

> The tier3 discussion might be about some passwd tools, for example these
> are also provided by u-l: chfn, chsh. (Note: there are many other tools
> in src:shadow passwd package that are not part of u-l.)
> Maybe after that we could consider if Priority: required is the correct
> one for passwd package (required means it's part of --variant=minbase
> where I think it's questionable if it's always needed. Also libuuid1
> currently depending on passwd will need to be revisited. We should
> be able to drop the old migration code from libuuid1 maintainer
> scripts and drop the dependency.)

I need more time to dive into these questions and comments are welcome.

>
> What do you think about the specific tools and packages?
> Which ones specifically would you like to see provided by
> util-linux instead (or if others which one?) and why?

I need to get more familiar with the shadow codebase (and with u-l) to
answer those questions.

>
>
> (Goes without saying, but ofcourse any of these plans are
> at this point targeted for Buster development cycle.)

Sure. My short time plan is going through the shadow bugs to see what
needs to be fixed for Jessie. After I'm done with them I will be in a
much better position for answering the remaining questions.

Cheers,
Balint

>
>
> [...]
>> Maybe discussing the bigger picture on
>> pkg-auth-maintainers@lists.alioth.debian.org would help the planning.
>
> Sure, added to CC for now. Lets drop the bug report if we drift
> too far off-topic for it.
>
>>
>> >
>> > Also someone needs to make sure the different implementation of the
>> > tools are actually 100% compatible or what migrations we need to handle
>> > on package upgrades.
>> >
>> > Please note that while "login" is Essential: yes, the "passwd" package
>> > is not. Things to keep in mind when expanding util-linux is that
>> > all tools then become Essential: yes which I think is unfortunate as
>> > we should strive to keep the essential set as small as possible.
>>
>> Rebootstrapping [1] already covers util-linux thus I think building
>> login from util-linux would not cause big problems.
>>
>> Cheers,
>> Balint
>>
>> [1] https://anonscm.debian.org/cgit/users/helmutg/rebootstrap.git/
>
> Regards,
> Andreas Henriksson

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

From: "Serge E. Hallyn" <serge@hallyn.com>

To: 833256@bugs.debian.org

Subject: shadow and util-linux

Date: Tue, 17 Jan 2017 13:59:49 -0600

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.

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

From: Andreas Henriksson <andreas@fatal.se>

To: "Serge E. Hallyn" <serge@hallyn.com>, 833256@bugs.debian.org

Subject: Re: Bug#833256: shadow and util-linux

Date: Thu, 19 Jan 2017 23:40:46 +0100

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

Hello Serge E. Hallyn,

Thanks for your input.

On Tue, Jan 17, 2017 at 01:59:49PM -0600, Serge E. Hallyn wrote:
> Hi,
> 
> so it looks like things which are duplicated include:
> 
> chfn
> chsh
> (but not chpasswd?)
> newgroup
> su
> vipw

I've done a quick comparison of what the manpage says in
shadow vs util-linux for these tools.... (Actual implementation
might still differ.)

I'm attaching a text file with my findings for all the above listed
tools.

> 
> 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?)  

No, util-linux su does not implement all login.defs variables
that shadow su supports. Not sure how relevant the missing ones are.
Input very welcome! Would it maybe be enough to list the unsupported
ones in NEWS.Debian to alert dist-upgraders of the change?

> Are the manpages sufficient in util-linux  (I think so)?

Yes, that is my impression. While the actual tools maybe should grow
some (or all?) of the options missing from the shadow equivalent the
manpages should then be extended at the same time ofcourse.

>  What about the internationalization?  (Seems to
> be there, at least)

Should work.

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

I have no personal imminent plans. Please check with upstream.
It's likely they'll say yes and possibly even have volunteers that does
the work.
Would be great if shadow (upstream) maintainers could reach out directly
to util-linux upstream to discuss about a unified vision. ;)

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

More fine-grained equivalence studies likely needed.
Personally I don't think we have to make it a show-stopper for
everything to be equivalently supported. Some might have no users and
may just be a waste to implement, where just a NEWS.Debian entry can
suffice. (Others we might really want to implement, and some we
likely should implement but might not be show-stoppers.)
Input on the importance of each spotted difference welcome.

> 
> 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.
> 

Regards,
Andreas Henriksson

[shadow-comparison.txt (text/plain, attachment)]

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

From: Andreas Henriksson <andreas@fatal.se>

To: "Serge E. Hallyn" <serge@hallyn.com>, 833256@bugs.debian.org

Subject: Re: Bug#833256: shadow and util-linux

Date: Sun, 22 Jan 2017 16:18:29 +0100

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.

More details below.... Feedback very welcome!

>
> # su

I was told by util-linux upstream that there was previously a difference
in goals, where shadow would care about historical things like systems
that did not have PAM. I interpret this that there's no real interest in
introducing these legacy things in util-linux, so in case anyone wants
to preserve those it's probably better to continue the shadow (upstream)
implementations for that. This isn't as I can see anything to be
considered in Debian though.


>
> The util-linux version supports all command-line options listed in
> shadow su manpage.  Possible slight implementation details might
> differ for example in -p (needs investigation).
>
> The util-linux version does not support the following shadow su
> login.defs variables:
>
> CONSOLE_GROUPS

Manpage description makes this sound like a bad idea to implement.

Looking at source:
http://sources.debian.net/src/shadow/1:4.4-2/src/su.c/#L1089
http://sources.debian.net/src/shadow/1:4.4-2/libmisc/setugid.c/#L132
... and build logs:
https://buildd.debian.org/status/fetch.php?pkg=shadow&arch=amd64&ver=1%3A4.4-2&stamp=1484851064&raw=0

It seems that HAVE_INITGROUPS is true and USE_PAM is also true, making
the preprocessor condition false which mean we don't build with
CONSOLE_GROUPS support in Debian shadow su.

The login.defs manpage should probably document this setting is not
considered when PAM is enabled (which would be extremely common these
days).


=> CONSOLE_GROUPS (non-)existance can safely be ignored.


> DEFAULT_HOME

util-linux has the opposite default (only warn), and doesn't support
manual configuring this setting.
http://sources.debian.net/src/util-linux/2.29.1-1/login-utils/su-common.c/#L979

Might be useful to implement support for this setting in util-linux.
Question remains about default, maybe implement a configure time setting
for the default?

How much do we really care about this setting though?

I personally don't think this is a blocker (for su - for login it would
be important to support it), would rather consider it a wishlist feature
request than anyone is free to submit a patch to upstream for if they
want to see it supported.


=> consider as potential wishlist-severity feature request if anyone is
   interested?!


> SULOG_FILE

It seems shadow had the intention for *optional* support of syslog (but
it's actually always enabled at compile-time and configurable at
runtime), and non-optional support for built-in logging system. This is
likely something we want the opposite way around in a modern system, so
I'd advocate for deprecating this option if we move to util-linux su.


=> consider deprecated?! (Possibly implement a warning on upgrades on
   systems which has it set?)


> SU_NAME

This seems like a pretty superficial feature to me.

(Note: messing with argv0 also seems to cause problems when busybox
is being used as /bin/sh as experienced by OpenEmbedded.)


=> consider deprecated?!


> SYSLOG_SU_ENAB

In util-linux syslog logging is mandatory. I don't see a reason to be
able to switch it off.


=> consider deprecated?!


----

Also note the following su related patches carried in Debian shadow package:
http://sources.debian.net/src/shadow/1:4.4-2/debian/patches/523_su_arguments_are_concatenated/
http://sources.debian.net/src/shadow/1:4.4-2/debian/patches/523_su_arguments_are_no_more_concatenated_by_default/
Both seems obsolete (the second one even says to be dropped after etch
which was released 2007).
(Also pbuilder seems to have switched from su to start-stop-daemon.)



Regards,
Andreas Henriksson

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

From: Christian Hofstaedtler <zeha@debian.org>

To: Andreas Henriksson <andreas@fatal.se>, 833256@bugs.debian.org

Cc: "Serge E. Hallyn" <serge@hallyn.com>, Bálint Réczey <balint@balintreczey.hu>, Laurent Bigonville <bigon@debian.org>, pkg-auth-maintainers@lists.alioth.debian.org

Subject: Re: Bug#833256: shadow and util-linux

Date: Sun, 22 Jan 2017 16:40:31 +0100

Chiming in here because I can send email.

* Andreas Henriksson <andreas@fatal.se> [170122 15:31]:
> [andreas was looking at the unsupported features in su from
> util-linux]:
> [..]
>
> > DEFAULT_HOME
> 
> util-linux has the opposite default (only warn), and doesn't support
> manual configuring this setting.
> http://sources.debian.net/src/util-linux/2.29.1-1/login-utils/su-common.c/#L979
> 
> Might be useful to implement support for this setting in util-linux.
> Question remains about default, maybe implement a configure time setting
> for the default?
> 
> How much do we really care about this setting though?
> 
> I personally don't think this is a blocker (for su - for login it would
> be important to support it), would rather consider it a wishlist feature
> request than anyone is free to submit a patch to upstream for if they
> want to see it supported.
> 
> 
> => consider as potential wishlist-severity feature request if anyone is
>    interested?!

The /etc/login.defs file as shipped in login today has this set to
"yes". Having login and su behave differently does not appear to be an
option today, so I don't think "no" for this setting is actually important?


> > SULOG_FILE
> 
> It seems shadow had the intention for *optional* support of syslog (but
> it's actually always enabled at compile-time and configurable at
> runtime), and non-optional support for built-in logging system. This is
> likely something we want the opposite way around in a modern system, so
> I'd advocate for deprecating this option if we move to util-linux su.
> 
> 
> => consider deprecated?! (Possibly implement a warning on upgrades on
>    systems which has it set?)

+1

> > SU_NAME
> 
> This seems like a pretty superficial feature to me.
> 
> (Note: messing with argv0 also seems to cause problems when busybox
> is being used as /bin/sh as experienced by OpenEmbedded.)
> 
> => consider deprecated?!

+1

> > SYSLOG_SU_ENAB
> 
> In util-linux syslog logging is mandatory. I don't see a reason to be
> able to switch it off.
> 
> 
> => consider deprecated?!

+1

> ----
> 
> Also note the following su related patches carried in Debian shadow package:
> http://sources.debian.net/src/shadow/1:4.4-2/debian/patches/523_su_arguments_are_concatenated/
> http://sources.debian.net/src/shadow/1:4.4-2/debian/patches/523_su_arguments_are_no_more_concatenated_by_default/
> Both seems obsolete (the second one even says to be dropped after etch
> which was released 2007).
> (Also pbuilder seems to have switched from su to start-stop-daemon.)

Dropping the second one sure sounds safe, but the first one looks
like it changes commonly used behaviour? How does su from util-linux handle
that?


Cheers,
-- 
christian hofstaedtler <zeha@debian.org>

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

From: "Serge E. Hallyn" <serge@hallyn.com>

To: Andreas Henriksson <andreas@fatal.se>

Cc: 833256@bugs.debian.org

Subject: Re: Bug#833256: shadow and util-linux

Date: Sun, 22 Jan 2017 09:59:40 -0600

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.

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

From: Laurent Bigonville <bigon@debian.org>

To: "Serge E. Hallyn" <serge@hallyn.com>

Cc: 833256@bugs.debian.org, Andreas Henriksson <andreas@fatal.se>

Subject: Re: Bug#833256: shadow and util-linux

Date: Sun, 22 Jan 2017 17:13:57 +0100

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

On Sun, 22 Jan 2017 09:59:40 -0600 "Serge E. Hallyn" <serge@hallyn.com> 
wrote:
> 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.

Is debian as project supposed to support the non-PAM usecase? All the 
rest of the stack is using PAM already

[Message part 2 (text/html, inline)]

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

From: Laurent Bigonville <bigon@debian.org>

To: "Serge E. Hallyn" <serge@hallyn.com>

Cc: 833256@bugs.debian.org, Andreas Henriksson <andreas@fatal.se>

Subject: Re: Bug#833256: shadow and util-linux

Date: Sun, 22 Jan 2017 17:17:33 +0100

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

Le 22/01/17 à 17:13, Laurent Bigonville a écrit :
> On Sun, 22 Jan 2017 09:59:40 -0600 "Serge E. Hallyn" 
> <serge@hallyn.com> wrote:
> > 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.
>
> Is debian as project supposed to support the non-PAM usecase? All the 
> rest of the stack is using PAM already
But indeed, upstream should probably keep it, just checked slackaware 
and they are using the shadow implementation for /bin/login, maybe 
shadow upstream should talk to them.

[Message part 2 (text/html, inline)]

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

From: Christian Hofstaedtler <zeha@debian.org>

To: Andreas Henriksson <andreas@fatal.se>, 833256@bugs.debian.org

Cc: "Serge E. Hallyn" <serge@hallyn.com>, Bálint Réczey <balint@balintreczey.hu>, Laurent Bigonville <bigon@debian.org>, pkg-auth-maintainers@lists.alioth.debian.org

Subject: Re: Bug#833256: shadow and util-linux

Date: Sun, 22 Jan 2017 18:08:12 +0100

* Christian Hofstaedtler <zeha@debian.org> [170122 17:06]:
> * Andreas Henriksson <andreas@fatal.se> [170122 15:31]:
> > Also note the following su related patches carried in Debian shadow package:
> > http://sources.debian.net/src/shadow/1:4.4-2/debian/patches/523_su_arguments_are_concatenated/
> > http://sources.debian.net/src/shadow/1:4.4-2/debian/patches/523_su_arguments_are_no_more_concatenated_by_default/
> > Both seems obsolete (the second one even says to be dropped after etch
> > which was released 2007).
> > (Also pbuilder seems to have switched from su to start-stop-daemon.)
> 
> Dropping the second one sure sounds safe, but the first one looks
> like it changes commonly used behaviour? How does su from util-linux handle
> that?

After some testing (and discussion on IRC), I can't find a
difference in -c and -- handling between u-l su and Debian's current
su *. So whatever those patches do exactly, they are not preventing
us from switching.

* ignoring the extra env var SU_NO_SHELL_ARGS that Debian's su supports.

-- 
christian hofstaedtler <zeha@debian.org>

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

From: Christian Hofstaedtler <zeha@debian.org>

To: 833256@bugs.debian.org

Subject: Patch for tryout

Date: Sun, 22 Jan 2017 18:13:53 +0100

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

For anyone wanting to try the binaries from u-l, here's a simple
(and likely wrong) patch against u-l git, that produces a
util-linux.deb with the binaries included.

Use at your own risk :-)

[0001-Build-login-nologin-su-chsh-chfn-from-this-package.patch (text/plain, attachment)]

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

From: Christian Hofstaedtler <zeha@debian.org>

To: Andreas Henriksson <andreas@fatal.se>, 833256@bugs.debian.org

Cc: "Serge E. Hallyn" <serge@hallyn.com>

Subject: Re: Bug#833256: shadow and util-linux

Date: Sun, 22 Jan 2017 18:47:13 +0100

* Andreas Henriksson <andreas@fatal.se> [170122 17:25]:
> [..]
> # chsh
> 
> shadow				util-linux
> ================================================================
> -h (== --help)			-u (== --help)
> 
> -R chroot-dir
> --root chroot-dir
> 
> (not listing the options only existing in util-linux)
> 
> 
> The strict validation of only valid shells allowed for non-root seems
> to be a COMPILE-TIME "opt-in" feature in util-linux version:
> --enable-chsh-only-listed
> (Default in util-linux is to just warn when setting shell not listed in /etc/shells.)

From a quick look at 2.29.1-1, it appears to be a compile-time
opt-out feature. From ./configure --help:
  --disable-chsh-only-listed
                          chsh: allow shells not in /etc/shells


> # newgrp
> 
> The optional command-line '-' in shadow not supported in util-linux version.
> 
> The shadow man page is much longer and describes possible additional functionality in shadow version (this needs further investigation):
> 
> * password prompting
> * gshadow

u-l newgrp reads gshadow (and falls back to group) for the password,
and does password prompting, if a password is set.

> The shadow version has (compile-time optional) support for login.defs variable SYSLOG_SG_ENAB but that's not available in (any) util-linux tool.

Note that in shadow, this is compile-time and run-time enabled in Debian.


> # vipw
> 
> The shadow version of vipw and vigr supports many command-line options, while the util-linux equivalents only supports:
> 
> -h --help
> (-V --version)

The biggest issue I'm seeing there is the behaviour rgd. the shadow
files.
shadow vipw/vigr allow you to say --shadow to just edit the respective
shadow file.
u-l vipw/vigr do not have this flag, and interactively prompt after
editing the normal file, if the user wants to change the shadow
file too.

shadow vipw/vigr also have --passwd/--group, but personally I see no
value in supporting `vigr --passwd` ...

-- 
christian hofstaedtler <zeha@debian.org>

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

From: Tom H <tomh0665@gmail.com>

To: 833256@bugs.debian.org

Subject: Handling of environment variables

Date: Fri, 24 Feb 2017 07:11:01 -0500

There's a difference in the handling of environment variables between
the two implementations.

su provided by login/src:shadow resets
HOME
LOGNAME
PATH
SHELL
USER

su provided by util-linux resets
HOME
SHELL


I changed:

th's PATH to "/usr/sbin:/usr/bin:/sbin:/bin"
root's PATH to "/root/bin:/usr/sbin:/usr/bin:/sbin:/bin"
root's shell to "/bin/mksh"


Output:


Debian 9

th@localhost ~ $ echo $HOME $LOGNAME $PATH $SHELL $USER
/home/th th /usr/sbin:/usr/bin:/sbin:/bin /bin/bash th

th@localhost ~ $ su

root@localhost /home/th # echo $HOME $LOGNAME $PATH $SHELL $USER
/root root /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/bin/mksh root

root@localhost /home/th # grep SUPATH /etc/login.defs
# Three items must be defined:  MAIL_DIR, ENV_SUPATH, and ENV_PATH.
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

root@localhost /home/th # grep PATH= .profile
PATH="/root/bin:/usr/sbin:/usr/bin:/sbin:/bin"


RHEL 7

th@localhost ~ $ echo $HOME $LOGNAME $PATH $SHELL $USER
/home/th th /usr/sbin:/usr/bin:/sbin:/bin /bin/bash th

th@localhost ~ $ su

root@localhost /home/th # echo $HOME $LOGNAME $PATH $SHELL $USER
/root th /usr/sbin:/usr/bin:/sbin:/bin /bin/mksh th

root@localhost /home/th # grep PATH= .profile
PATH="/root/bin:/usr/sbin:/usr/bin:/sbin:/bin"

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

From: Andreas Henriksson <andreas@fatal.se>

To: Tom H <tomh0665@gmail.com>, 833256@bugs.debian.org

Subject: Re: Bug#833256: Handling of environment variables

Date: Sun, 26 Feb 2017 18:08:25 +0100

Hello Tom H,

Thanks for your feedback here pointing out this difference.

On Fri, Feb 24, 2017 at 07:11:01AM -0500, Tom H wrote:
> There's a difference in the handling of environment variables between
> the two implementations.
> 
> su provided by login/src:shadow resets
> HOME
> LOGNAME
> PATH
> SHELL
> USER

(As documented in su(1) from src:shadow.)

> 
> su provided by util-linux resets
> HOME
> SHELL
[...]

... when switching to uid 0.

When switching to another uid it also resets LOGNAME and USER.
http://sources.debian.net/src/util-linux/2.29.1-1/login-utils/su-common.c/#L564

(And PATH if ALWAYS_SET_PATH is set in login.defs.)
http://sources.debian.net/src/util-linux/2.29.1-1/login-utils/su-common.c/#L513

Thus the difference is smaller then it first seemed.... But definitely
a difference.

To me this mostly seems like a(nother) case of "always use 'su -', never
su".

I did some archeology to find out more about the special-casing of uid 0
here, but found out that this condition has existed in util-linux
version since the initial commit.

Would be interesting to hear if anyone knows more about this and if they
know anything that'll be affected by this difference if we switch.

Regards,
Andreas Henriksson

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

From: Tom H <tomh0665@gmail.com>

To: 833256@bugs.debian.org

Cc: Andreas Henriksson <andreas@fatal.se>

Subject: Re: Bug#833256: Handling of environment variables

Date: Mon, 27 Feb 2017 21:52:19 -0500

On Sun, Feb 26, 2017 at 12:08 PM, Andreas Henriksson <andreas@fatal.se> wrote:
> On Fri, Feb 24, 2017 at 07:11:01AM -0500, Tom H wrote:


> Thanks for your feedback here pointing out this difference.

You're welcome.


>> There's a difference in the handling of environment variables between
>> the two implementations.
>>
>> su provided by login/src:shadow resets
>> HOME
>> LOGNAME
>> PATH
>> SHELL
>> USER
>
> (As documented in su(1) from src:shadow.)
>
>> su provided by util-linux resets
>> HOME
>> SHELL
> [...]
>
> ... when switching to uid 0.
>
> When switching to another uid it also resets LOGNAME and USER.
> http://sources.debian.net/src/util-linux/2.29.1-1/login-utils/su-common.c/#L564

I should've read the man page before posting. I simply remembered the
envvar difference from a problem that we once hit at work.


> (And PATH if ALWAYS_SET_PATH is set in login.defs.)
> http://sources.debian.net/src/util-linux/2.29.1-1/login-utils/su-common.c/#L513

Not in Fedora and RHEL; hence $PATH was not reset in my "su" example.

So Debian would have to add "ALWAYS_SET_PATH yes" to "/etc/login.defs"
to preserve its current behavior.


> Thus the difference is smaller then it first seemed.... But definitely
> a difference.
>
> To me this mostly seems like a(nother) case of "always use 'su -', never
> su".

Definitely. And "sudo -i"/"sudo -i ...".


> I did some archeology to find out more about the special-casing of uid 0
> here, but found out that this condition has existed in util-linux
> version since the initial commit.
>
> Would be interesting to hear if anyone knows more about this and if they
> know anything that'll be affected by this difference if we switch.

util-linux's su is based on coreutils. The earliest su version that I
can find has the same uninformative (as to the rationale) comment as
currently:

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/su.c?h=SH-UTILS-1_12a#n379

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

From: Andreas Henriksson <andreas@fatal.se>

To: 833256@bugs.debian.org

Subject: login utility difference between shadow and util-linux

Date: Sat, 15 Jul 2017 12:44:58 +0200

For the record,

It seems we've missed investigating the actual '/usr/bin/login' binary
until now. I've quickly looked at it and there's one (documented)
difference spotted:

 * the util-linux version does not support the -r flag.

Here's the what login(1) manpage in util-linux says about it:

[...]
BUGS
       The undocumented BSD -r option is not supported.  This may be  required
       by some rlogind(8) programs.
[...]

Here's what the shadow login(1) manpage has to say about it:

[...]
SYNOPSIS
[...]
       login [-p] -r host
[...]
OPTIONS
[...]
       -r
           Perform autologin protocol for rlogin.

       The -r, -h and -f options are only used when login is invoked by root.
[...]

Question remains how widely used this feature is? Can we drop it?

Regards,
Andreas Henriksson

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

From: Andreas Henriksson <andreas@fatal.se>

To: 833256@bugs.debian.org

Subject: login.defs: debian shipped vs util-linux builtin defaults

Date: Sun, 30 Jul 2017 21:32:53 +0200

For the record...

While investigating the (currently) shipped /etc/login.defs default
settings and comparing the relevant fields to the builtin defaults
in the util-linux counterparts I noticed the following differences:

# CHFN_RESTRICT

- /etc/login.defs contains "rwh" by default.
  (In util-linux "yes" is also an alias for "rwh".)
  In util-linux all fields are restricted and this is documented.
  Action: I suspect we can live with this difference by just writing
  about it in NEWS.Debian on upgrade.


# ENV_PATH

- /etc/login.defs and util-linux builtin default is same except:
  /etc/login.defs has '/usr/local/games:/usr/games' appended.
  Action: check if util-linux upstream is willing to add these
  extra directories to the builtin default.

My general feeling is that we can likely get away with not shipping
any /etc/login.defs file at all if we want (or ship one with just
commented out examples).

Regards,
Andreas Henriksson

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

From: Josh Triplett <josh@joshtriplett.org>

To: 833256@bugs.debian.org

Subject: Re: login.defs: debian shipped vs util-linux builtin defaults

Date: Sat, 28 Jul 2018 12:26:30 -0700

On Sun, 30 Jul 2017 21:32:53 +0200 Andreas Henriksson <andreas@fatal.se> wrote:
> My general feeling is that we can likely get away with not shipping
> any /etc/login.defs file at all if we want (or ship one with just
> commented out examples).

The former, please; examples can go in /usr/share/doc. When trying to
build minimal systems, and in particular stateless or near-stateless
systems with configurations as close as possible to the default, it
helps to not have packages shipping configuration files consisting
entirely of comments.

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

From: Andreas Henriksson <andreas@fatal.se>

To: 833256@bugs.debian.org

Subject: su takeover done

Date: Tue, 7 Aug 2018 18:44:34 +0200

Control: retitle -1  util-linux: Please use login/passwd implementations provided by util-linux

Hello,

So the /bin/su takeover has recently been done.
Implementation was in shadow 1:4.5-1.1 and util-linux 2.32-0.2.
Testing migration has already happened and this is thus in for Buster
release.

This should be a good preparation step for migrating the rest of the
tools over to the util-linux implementation. Hopefully we can make login
and passwd packages non-Essential while at it. Exact details on how to
implement the switch needs to be further studied, but many details has
already been investigated and is part of the backlog of this bug report.

Retitling this bug report accordingly.

Please note that the Breaks/Depends relationship between
login and util-linux is "backwards". This is needed to trick apt into
unpacking new util-linux before new login (thus leaving no gap during
upgrade where /bin/su is not available). The relationship can be
switched around again once upgrade has been performed (after buster
release as far as debian is concerned, but maybe also wait until after
next ubuntu LTS? Depends on how the situation looks after entire
takeover is implemented I guess).

Regards,
Andreas Henriksson

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

From: Bálint Réczey <balint@balintreczey.hu>

To: 833256@bugs.debian.org

Cc: Andreas Henriksson <andreas@fatal.se>, Josh Triplett <josh@joshtriplett.org>, Tom H <tomh0665@gmail.com>, Christian Hofstaedtler <zeha@debian.org>, Laurent Bigonville <bigon@debian.org>, "Serge E. Hallyn" <serge@hallyn.com>

Subject: Re: util-linux: Please use login/passwd implementations provided by util-linux

Date: Mon, 11 Nov 2019 16:10:01 +0100

Hi All,

I'm now a bit less convinced that the switch its worth the pain of
getting through the transition, but I'm still not strongly against it.

To move forward I have created a branch where MRs are welcome:
https://salsa.debian.org/debian/shadow/commits/move-login-to-util-linux.

I' have also converted the shadow the package to dh and cleaned up it
a bit. /etc/securetty is dropped, so we don't have to drop it if the
move to util-linux finally happens.

Cheers,
Balint

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

From: Chris Hofstaedtler <zeha@debian.org>

To: balint@balintreczey.hu, 833256@bugs.debian.org

Cc: Andreas Henriksson <andreas@fatal.se>, Josh Triplett <josh@joshtriplett.org>, Tom H <tomh0665@gmail.com>, Laurent Bigonville <bigon@debian.org>, "Serge E. Hallyn" <serge@hallyn.com>

Subject: Re: Bug#833256: util-linux: Please use login/passwd implementations provided by util-linux

Date: Sun, 3 May 2020 21:19:41 +0200

Hi Bálint,

* Bálint Réczey <balint@balintreczey.hu> [200503 19:18]:
> I'm now a bit less convinced that the switch its worth the pain of
> getting through the transition, but I'm still not strongly against it.
> 
> To move forward I have created a branch where MRs are welcome:
> https://salsa.debian.org/debian/shadow/commits/move-login-to-util-linux.

Thanks for working on this. I'll try to see what we need to do on
the util-linux side soon.

> I' have also converted the shadow the package to dh and cleaned up it
> a bit. /etc/securetty is dropped, so we don't have to drop it if the
> move to util-linux finally happens.

Awesome.

Thanks,
Chris

Send a report that this bug log contains spam.