Re: Bookworm: missing sbin in root path?

[Henning Follmann]

On Sat, Jul 01, 2023 at 10:07:59PM -0400, Carl Fink wrote:
> 
> On 7/1/23 21:38, Greg Wooledge wrote:
> > On Sat, Jul 01, 2023 at 08:58:44PM -0400, Carl Fink wrote:
> > > When I type "/usr/sbin/adduser", that works, but shouldn't root default to
> > > having sbin in its path?
> > You probably used su.
> > 
[...]
> Yes, I did use su. I had no idea that would cause a problem.
> 
> Thanks for the pointer. I created /etc/default/su, which should
> resolve this.
> 

or using:
su -

This will include your environment for root

-H

-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: Bookworm: missing sbin in root path?

[Carl Fink]

Yes, I did use su. I had no idea that would cause a problem.

Thanks for the pointer. I created /etc/default/su, which should
resolve this.

 -Carl Fink

On 7/1/23 21:38, Greg Wooledge wrote:

On Sat, Jul 01, 2023 at 08:58:44PM -0400, Carl Fink wrote:

When I type "/usr/sbin/adduser", that works, but shouldn't root default to
having sbin in its path?

You probably used su.

<https://wiki.debian.org/NewInBuster#Changes> describes the change
and the known fixes.

Re: Bookworm: missing sbin in root path?

[Greg Wooledge]

On Sat, Jul 01, 2023 at 08:58:44PM -0400, Carl Fink wrote:
> When I type "/usr/sbin/adduser", that works, but shouldn't root default to
> having sbin in its path?

You probably used su.

<https://wiki.debian.org/NewInBuster#Changes> describes the change
and the known fixes.

Bookworm: missing sbin in root path?

[Carl Fink]

Hi,

So I just installed Debian Bookworm on a new system. And things aren't 
there. I noticed that "adduser is already the newest version (3.134)." 
(according to Apt) but typing "adduser" at a terminal prompt does ... 
nothing. Not found.


So, I installed locate (also not present by default?) and discovered 
that although the package installed /usr/sbin/adduser, somehow root 
doesn't have /user/sbin in its PATH.


When I type "/usr/sbin/adduser", that works, but shouldn't root default 
to having sbin in its path?


-Carl Fink

Re: /sbin vs /bin

[Dan Ritter]

to...@tuxteam.de wrote: 
> On Sat, Jul 30, 2022 at 02:07:58PM -0400, Greg Wooledge wrote:
> > On Sat, Jul 30, 2022 at 02:02:21PM -0400, Timothy M Butterworth wrote:
> > > Logging in as root has become taboo. Sudo is the prefered mechanism for
> > > running administrator functions. I have root set to nologin with a null
> > > password to force sudo usage.
> > 
> > This makes entering single-user mode ("rescue mode") impossible.
> 
> Agreed. There are ways around that, but logging in as root while
> physically present is a quite honourable thing to do.
> 
> Some swing this way, others the other way. Use the tool which suits
> you. Know its limitations.
> 
> FWIW, not long ago sudo had a vulnerability. It is just much more
> complex, and complexity is an enemy of security (I say that as a
> fan of sudo and as a regular user).

The OpenBSD folk created "doas", which is packaged in Bullseye. 

Description: minimal replacement for sudo
 OpenDoas: a portable version of OpenBSD's doas command
 doas is a minimal replacement for the venerable sudo. It was
 initially written by Ted Unangst of the OpenBSD project to provide 95% of the
 features of sudo with a fraction of the codebase.

I haven't used it, but I suspect it is excellent for
single-sysadmin machines.

-dsr-

Re: /sbin vs /bin

[David Wright]

On Sat 30 Jul 2022 at 20:21:00 (+0200), to...@tuxteam.de wrote:
> On Sat, Jul 30, 2022 at 02:07:58PM -0400, Greg Wooledge wrote:
> > On Sat, Jul 30, 2022 at 02:02:21PM -0400, Timothy M Butterworth wrote:
> > > Logging in as root has become taboo. Sudo is the prefered mechanism for
> > > running administrator functions. I have root set to nologin with a null
> > > password to force sudo usage.
> > 
> > This makes entering single-user mode ("rescue mode") impossible.
> 
> Agreed. There are ways around that, but logging in as root while
> physically present is a quite honourable thing to do.
> 
> Some swing this way, others the other way. Use the tool which suits
> you. Know its limitations.
> 
> FWIW, not long ago sudo had a vulnerability. It is just much more
> complex, and complexity is an enemy of security (I say that as a
> fan of sudo and as a regular user).

> > > I would love to see Debian Bookworm disable
> > > root login by default.

Why? Any competent sysadmin can do that themselves easily enough.
The choices offered by the d-i are quite sufficient for a home user.

Cheers,
David.

Re: /sbin vs /bin

[tomas]

On Sat, Jul 30, 2022 at 02:07:58PM -0400, Greg Wooledge wrote:
> On Sat, Jul 30, 2022 at 02:02:21PM -0400, Timothy M Butterworth wrote:
> > Logging in as root has become taboo. Sudo is the prefered mechanism for
> > running administrator functions. I have root set to nologin with a null
> > password to force sudo usage.
> 
> This makes entering single-user mode ("rescue mode") impossible.

Agreed. There are ways around that, but logging in as root while
physically present is a quite honourable thing to do.

Some swing this way, others the other way. Use the tool which suits
you. Know its limitations.

FWIW, not long ago sudo had a vulnerability. It is just much more
complex, and complexity is an enemy of security (I say that as a
fan of sudo and as a regular user).

Cheers
-- 
"all generalisations suck" tomás


signature.asc
Description: PGP signature

Re: /sbin vs /bin

[Greg Wooledge]

On Sat, Jul 30, 2022 at 02:02:21PM -0400, Timothy M Butterworth wrote:
> Logging in as root has become taboo. Sudo is the prefered mechanism for
> running administrator functions. I have root set to nologin with a null
> password to force sudo usage.

This makes entering single-user mode ("rescue mode") impossible.

> One of the major issues with su root is that
> in a work environment with more than one administrator you would have to
> share the root password. Sharing one account provided no accountability as
> to who actually made changes. I would love to see Debian Bookworm disable
> root login by default. Root is a security vulnerability because the user
> name is known so it is easy to launch a brute force attack against the
> server.

If it's about "attacking a server", the default sshd configuration which
disallows root logins is already sufficient.  There's no reason to stop
people from using a root password locally, to stop single-user mode from
working, etc.

(Of course, if that's what you want on *your* systems, you're free to do
that.  I just don't think it's necessary to impose it on everyone else
by fiat.)

Re: /sbin vs /bin

[Timothy M Butterworth]

On Fri, Jul 29, 2022 at 7:08 AM Greg Wooledge  wrote:

> On Thu, Jul 28, 2022 at 11:39:01PM -0500, Igor Korot wrote:
> > Open the Terminal
> > Become root by running su
> > Try to run ldconfig -> "Command not found"
> > Try to run /sbin/ldconfig -> execution successful
>
> https://wiki.debian.org/NewInBuster#Changes
>
>   Changes
>
> The su command in buster is provided by the util-linux source package,
> instead of the shadow source package, and no longer alters the PATH
> variable by default. This means that after doing su, your PATH may
> not contain directories like /sbin, and many system administration
> commands will fail. There are several workarounds:
>
>  *  Use su - instead; this launches a login shell, which forces PATH
> to be changed, but also changes everything else including the
> working directory.
>
>  *  Use sudo instead. sudo still runs commands with an altered
> PATH variable.
>
> o   To get a regular root shell with the correct PATH, you may
> use sudo -s.
>
> o   To get a login shell as root (equivalent to su -), you may
> use sudo -i.
>
>  *  Put ALWAYS_SET_PATH yes in /etc/default/su (create it) to get
> an approximation of the old behavior. This is documented in su(1).
>
>  *  Put the system administration directories (/sbin, /usr/sbin,
> /usr/local/sbin) in your regular account's PATH (see
> EnvironmentVariables for help with this).
>
> Logging in as root has become taboo. Sudo is the prefered mechanism for
running administrator functions. I have root set to nologin with a null
password to force sudo usage. One of the major issues with su root is that
in a work environment with more than one administrator you would have to
share the root password. Sharing one account provided no accountability as
to who actually made changes. I would love to see Debian Bookworm disable
root login by default. Root is a security vulnerability because the user
name is known so it is easy to launch a brute force attack against the
server.

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: /sbin vs /bin

[Greg Wooledge]

On Thu, Jul 28, 2022 at 11:39:01PM -0500, Igor Korot wrote:
> Open the Terminal
> Become root by running su
> Try to run ldconfig -> "Command not found"
> Try to run /sbin/ldconfig -> execution successful

https://wiki.debian.org/NewInBuster#Changes

  Changes

The su command in buster is provided by the util-linux source package,
instead of the shadow source package, and no longer alters the PATH
variable by default. This means that after doing su, your PATH may
not contain directories like /sbin, and many system administration
commands will fail. There are several workarounds:

 *  Use su - instead; this launches a login shell, which forces PATH
to be changed, but also changes everything else including the
working directory.

 *  Use sudo instead. sudo still runs commands with an altered
PATH variable.

o   To get a regular root shell with the correct PATH, you may
use sudo -s.

o   To get a login shell as root (equivalent to su -), you may
use sudo -i.

 *  Put ALWAYS_SET_PATH yes in /etc/default/su (create it) to get
an approximation of the old behavior. This is documented in su(1).

 *  Put the system administration directories (/sbin, /usr/sbin,
/usr/local/sbin) in your regular account's PATH (see
EnvironmentVariables for help with this).

Re: /sbin vs /bin

[tomas]

On Thu, Jul 28, 2022 at 11:39:01PM -0500, Igor Korot wrote:
> Hi, David,
> 
> On Thu, Jul 28, 2022 at 11:10 PM David Wright  
> wrote:
> >
> > On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote:
> > > According to 
> > > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386,
> > >
> > > ld config is located inside /sbin and it is installed through the 
> > > libc-bin.
> > >
> > > Trying to run ldconfig gives "No such file or directory"
> > > Running "apt install libc-bin" says "Its installed and already a latest
> > > version"
> > > Only running "/sbin/ldconfig" makes it run.
> > >
> > > Is "/sbin" not in the default PATH variable?
> >
> > For an ordinary user: no.
> >
> > For root: yes.
> 
> Wrong. ;-)
> Boot into an OS and login as a regular user.
> Open the Terminal
> Become root by running su

Ah, su. Don't use su unless you know very well what you are doing.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: /sbin vs /bin

[David Wright]

On Thu 28 Jul 2022 at 23:39:01 (-0500), Igor Korot wrote:
> On Thu, Jul 28, 2022 at 11:10 PM David Wright  
> wrote:
> > On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote:
> > > According to 
> > > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386,
> > >
> > > ld config is located inside /sbin and it is installed through the 
> > > libc-bin.
> > >
> > > Trying to run ldconfig gives "No such file or directory"
> > > Running "apt install libc-bin" says "Its installed and already a latest
> > > version"
> > > Only running "/sbin/ldconfig" makes it run.
> > >
> > > Is "/sbin" not in the default PATH variable?
> >
> > For an ordinary user: no.
> >
> > For root: yes.
> 
> Wrong. ;-)
> Boot into an OS and login as a regular user.
> Open the Terminal
> Become root by running su

You'd better get up to date on the change made to the behaviour of su.
If you run plain "su", you don't get root's default PATH variable,
but whatever it was before.

> Try to run ldconfig -> "Command not found"
> Try to run /sbin/ldconfig -> execution successful

Cheers,
David.

Re: /sbin vs /bin

[Igor Korot]

Hi, David,

On Thu, Jul 28, 2022 at 11:10 PM David Wright  wrote:
>
> On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote:
> > According to 
> > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386,
> >
> > ld config is located inside /sbin and it is installed through the libc-bin.
> >
> > Trying to run ldconfig gives "No such file or directory"
> > Running "apt install libc-bin" says "Its installed and already a latest
> > version"
> > Only running "/sbin/ldconfig" makes it run.
> >
> > Is "/sbin" not in the default PATH variable?
>
> For an ordinary user: no.
>
> For root: yes.

Wrong. ;-)
Boot into an OS and login as a regular user.
Open the Terminal
Become root by running su
Try to run ldconfig -> "Command not found"
Try to run /sbin/ldconfig -> execution successful

Thank you.

>
> Cheers,
> David.
>

Re: /sbin vs /bin

[tomas]

On Thu, Jul 28, 2022 at 11:10:07PM -0500, David Wright wrote:
> On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote:
> > According to 
> > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386,
> > 
> > ld config is located inside /sbin and it is installed through the libc-bin.
> > 
> > Trying to run ldconfig gives "No such file or directory"
> > Running "apt install libc-bin" says "Its installed and already a latest
> > version"
> > Only running "/sbin/ldconfig" makes it run.
> > 
> > Is "/sbin" not in the default PATH variable?
> 
> For an ordinary user: no.
> 
> For root: yes.

To complement this: if you do "sudo ldconfig" everything should work.
If you log in as root and do ldconfig, everything should work, too.
Note that you shouldn't be able to run ldconfig as non-root (it does
change files only root should be able to change).

So even if you try /sbin/ldconfig as a regular user (is it this what
you are trying to do?), it is going to fail at a latter stage.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: /sbin vs /bin

[David Wright]

On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote:
> According to 
> https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386,
> 
> ld config is located inside /sbin and it is installed through the libc-bin.
> 
> Trying to run ldconfig gives "No such file or directory"
> Running "apt install libc-bin" says "Its installed and already a latest
> version"
> Only running "/sbin/ldconfig" makes it run.
> 
> Is "/sbin" not in the default PATH variable?

For an ordinary user: no.

For root: yes.

Cheers,
David.

/sbin vs /bin

[Igor Korot]

Hi, ALL,
According to 
https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386,

ld config is located inside /sbin and it is installed through the libc-bin.

Trying to run ldconfig gives "No such file or directory"
Running "apt install libc-bin" says "Its installed and already a latest
version"
Only running "/sbin/ldconfig" makes it run.

Is "/sbin" not in the default PATH variable?

Thank you.

Re: What is z3fold and do I need it? (error: /usr/sbin/mkinitramfs: 12: /etc/initramfs-tools/conf.d/local.conf: z3fold: not found)

[Dekks Herton]

z3fold a choice for zsap compressor module, normally if your seeing a
problem you need to add z3fold to initramfs modules file and rebuild.

see 
https://baronhk.wordpress.com/2021/10/03/setting-up-zswap-in-debian-11-gnu-linux/

Re: What is z3fold and do I need it? (error: /usr/sbin/mkinitramfs: 12: /etc/initramfs-tools/conf.d/local.conf: z3fold: not found)

[Henrique de Moraes Holschuh]

On Fri, 04 Mar 2022, Ottavio Caruso wrote:
> ~$ sudo find /lib/modules/ -iname "*z3fold*"
> /lib/modules/4.19.0-17-amd64/kernel/mm/z3fold.ko
> /lib/modules/4.19.0-14-amd64/kernel/mm/z3fold.ko
> /lib/modules/4.19.0-8-amd64/kernel/mm/z3fold.ko
> 
> 
> Then why doesn't it load up?

update-initramfs -u -v, and check the debug output.  Maybe it will have
a hint on what failed.

-- 
  Henrique Holschuh

Re: What is z3fold and do I need it? (error: /usr/sbin/mkinitramfs: 12: /etc/initramfs-tools/conf.d/local.conf: z3fold: not found)

[Michael Lange]

Hi,

On Thu, 3 Mar 2022 07:25:01 -0500
Greg Wooledge  wrote:

(...)
> > /usr/sbin/mkinitramfs: 12: /etc/initramfs-tools/conf.d/local.conf:
> > z3fold: not found
> 
> Well, as your file says, this is supposed to be a kernel module.  On my
> system, I have this:
> 
> unicorn:~$ locate z3fold
> /lib/modules/5.10.0-10-amd64/kernel/mm/z3fold.ko
> /lib/modules/5.10.0-11-amd64/kernel/mm/z3fold.ko
> 
> However, you're running an oldstable (buster, Debian 10) kernel.  I
> don't know whether buster's kernels have this module.

they do:

$ locate z3fold
/lib/modules/4.19.0-17-amd64/kernel/mm/z3fold.ko
/lib/modules/4.19.0-18-amd64/kernel/mm/z3fold.ko

Have a nice day,

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?"  stardate 3468.1

Re: What is z3fold and do I need it? (error: /usr/sbin/mkinitramfs: 12: /etc/initramfs-tools/conf.d/local.conf: z3fold: not found)

[Greg Wooledge]

On Thu, Mar 03, 2022 at 10:21:45AM +, Ottavio Caruso wrote:
> I was following this guide:
> https://easylinuxtipsproject.blogspot.com/p/speed-mint.html#ID1.2
> 
> So I added:
> 
> # cat /etc/initramfs-tools/conf.d/local.conf
> # List of modules that you want to include in your initramfs.
> # They will be loaded at boot time in the order below.
> #
> # Syntax: module_name [args ...]
> #
> # You must run update-initramfs(8) to effect this change.
> #
> # Examples:
> #
> # raid1
> # sd_mod
> z3fold
> lz4
> 
> Then:
> 
> # update-initramfs -u
> 
> And I get error:
> 
> /usr/sbin/mkinitramfs: 12: /etc/initramfs-tools/conf.d/local.conf: z3fold:
> not found

Well, as your file says, this is supposed to be a kernel module.  On my
system, I have this:

unicorn:~$ locate z3fold
/lib/modules/5.10.0-10-amd64/kernel/mm/z3fold.ko
/lib/modules/5.10.0-11-amd64/kernel/mm/z3fold.ko

However, you're running an oldstable (buster, Debian 10) kernel.  I don't
know whether buster's kernels have this module.

The dangers of following a guide that's written for a *different* operating
system (Mint in this case) is that some or all of it might not apply
to *your* operating system.  This is especially true when you're not on
the current stable release of your operating system.

Re: /usr/sbin/reboot: disabled in systemd-nspawn container SOLVED

[Andrei POPESCU]

On Sb, 04 sep 21, 17:35:49, sp...@caiway.net wrote:
> SOLVED
> 
> /usr/share/open-infrastructure/container/shutdown.txt
> is from package progress-linux-container:
> 
> Progress Linux is a Debian derivative distribution focused on system
> integration.
> 
> This package is a metapackage to be installed in a container
> (systemd-nspawn).
> 
> # apt remove progress-linux-container

You should probably `purge` it, `remove` can leave stuff behind.

(didn't bother to check for this particular package, but anyway, I like 
my `dpkg -l` "clean")

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[Stefan Monnier]

Greg Wooledge [2021-09-04 11:35:25] wrote:
> On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp...@caiway.net wrote:
>> # file /sbin/reboot
>> /sbin/reboot: POSIX shell script, ASCII text executable
>
> That's not normal for a bullseye system using systemd for init.

Indeed.

> I'm not sure what you did or how your system got into this state.

Maybe

dpkg -S /sbin/reboot /usr/sbin/reboot

could give us a clue?


Stefan

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[sp...@caiway.net]

On Sat, 04 Sep 2021 14:46:21 -0400
The Wanderer  wrote:

> On 2021-09-04 at 13:20, Greg Wooledge wrote:
> 
> > On Sat, Sep 04, 2021 at 12:54:35PM -0400, Stefan Monnier wrote:
> >
> >> Greg Wooledge [2021-09-04 11:35:25] wrote:
> >> > On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp...@caiway.net wrote:
> >> >> # file /sbin/reboot

> 
> Based on what I read of the thread, that package is
> progress-linux-container.
> 
> $ apt-cache policy progress-linux-container
> progress-linux-container:
>   Installed: (none)
>   Candidate: 20210101-2
>   Version table:
>  20210101-2 900
> 800 http://ftp.us.debian.org/debian stable/main amd64 Packages
> 800 http://ftp.us.debian.org/debian stable/main i386 Packages
> 900 http://ftp.us.debian.org/debian testing/main amd64
> Packages 900 http://ftp.us.debian.org/debian testing/main i386
> Packages
> 
> progress-linux-container is a package in Debian, and at least at a
> glance, is apparently meant for installing on a Debian system. (Or
> else it made it from the downstream distribution into upstream Debian
> by mistake, somehow.)
> 
> It's just not meant for installing on a host system; it's meant for
> installing only inside a container.
> 
> What resulted in it being installed in the OP's case is unclear (the
> OP has said he doesn't know), but at least at a glance it doesn't
> look like this is a case of mixing different operating systems,
> unless I'm misunderstanding what you mean by that.
> 

Thw Wanderer, you are absolutely right
our posts may have crossed
the case is solved
see above


# apt remove progress-linux-container
solved the issue

and in addition,
I must have installed by hand, in the wrong place
in OS not inside container

my bad


glad it is cleared
thanks

sp007

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[The Wanderer]

On 2021-09-04 at 13:20, Greg Wooledge wrote:

> On Sat, Sep 04, 2021 at 12:54:35PM -0400, Stefan Monnier wrote:
>
>> Greg Wooledge [2021-09-04 11:35:25] wrote:
>> > On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp...@caiway.net wrote:
>> >> # file /sbin/reboot
>> >> /sbin/reboot: POSIX shell script, ASCII text executable
>> >
>> > That's not normal for a bullseye system using systemd for init.
>> 
>> Indeed.
>> 
>> > I'm not sure what you did or how your system got into this state.
>> 
>> Maybe
>> 
>> dpkg -S /sbin/reboot /usr/sbin/reboot
>> 
>> could give us a clue?
> 
> From the other part of the thread, it looks like they installed a
> package from a different operating system.  One that interfered with
> the Debian init system.
> 
> This is why we tell people: NEVER mix packages from different operating
> systems.  Especially low-level ones like systemd.

Based on what I read of the thread, that package is
progress-linux-container.

$ apt-cache policy progress-linux-container
progress-linux-container:
  Installed: (none)
  Candidate: 20210101-2
  Version table:
 20210101-2 900
800 http://ftp.us.debian.org/debian stable/main amd64 Packages
800 http://ftp.us.debian.org/debian stable/main i386 Packages
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
900 http://ftp.us.debian.org/debian testing/main i386 Packages

progress-linux-container is a package in Debian, and at least at a
glance, is apparently meant for installing on a Debian system. (Or else
it made it from the downstream distribution into upstream Debian by
mistake, somehow.)

It's just not meant for installing on a host system; it's meant for
installing only inside a container.

What resulted in it being installed in the OP's case is unclear (the OP
has said he doesn't know), but at least at a glance it doesn't look like
this is a case of mixing different operating systems, unless I'm
misunderstanding what you mean by that.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[Greg Wooledge]

On Sat, Sep 04, 2021 at 12:54:35PM -0400, Stefan Monnier wrote:
> Greg Wooledge [2021-09-04 11:35:25] wrote:
> > On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp...@caiway.net wrote:
> >> # file /sbin/reboot
> >> /sbin/reboot: POSIX shell script, ASCII text executable
> >
> > That's not normal for a bullseye system using systemd for init.
> 
> Indeed.
> 
> > I'm not sure what you did or how your system got into this state.
> 
> Maybe
> 
> dpkg -S /sbin/reboot /usr/sbin/reboot
> 
> could give us a clue?

>From the other part of the thread, it looks like they installed a
package from a different operating system.  One that interfered with
the Debian init system.

This is why we tell people: NEVER mix packages from different operating
systems.  Especially low-level ones like systemd.

Re: /usr/sbin/reboot: disabled in systemd-nspawn container SOLVED

[sp...@caiway.net]

SOLVED

/usr/share/open-infrastructure/container/shutdown.txt
is from package progress-linux-container:

Progress Linux is a Debian derivative distribution focused on system
integration.

This package is a metapackage to be installed in a container
(systemd-nspawn).

# apt remove progress-linux-container

let's see if this is the problem

YES

I have no idea why it was installed.

Thanks, Reco

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[Greg Wooledge]

On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp...@caiway.net wrote:
> On Sat, 4 Sep 2021 16:42:45 +0300
> Reco  wrote:
> 
> > Hi.
> > 
> > On Sat, Sep 04, 2021 at 02:40:13PM +0200, sp...@caiway.net wrote:
> > > Suddenly I can no longer reboot or poweroff my up-to-date
> > > bullseye system:
> > > 
> > > # reboot
> > > /usr/sbin/reboot: disabled in systemd-nspawn container
> > 
> > Unless I'm mistaken, these messages are not generated by systemd.
> > In fact, there's nothing that resembles such messages in systemd
> > sources.
> > 
> > So, try this, for starters:
> > 
> > /bin/systemd reboot
> > 
> 
> # /bin/systemd reboot
> Excess arguments.
> 
> > And, what about these:
> > 
> > ls -al /sbin/reboot
> 
> # ls -al /sbin/reboot
> -rwxr-xr-x 1 root root 319 Mar 24 05:22 /sbin/reboot
> 
> 
> > file /sbin/reboot
> > 
> 
> # file /sbin/reboot
> /sbin/reboot: POSIX shell script, ASCII text executable

That's not normal for a bullseye system using systemd for init.

unicorn:~$ ls -l /sbin/reboot
lrwxrwxrwx 1 root root 14 Jul 13 13:29 /sbin/reboot -> /bin/systemctl*

You might need to reinstall the systemd-sysv package, maybe.  I'm
not sure what you did or how your system got into this state.

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[Reco]

On Sat, Sep 04, 2021 at 04:49:24PM +0200, sp...@caiway.net wrote:
> On Sat, 4 Sep 2021 16:42:45 +0300
> Reco  wrote:
> 
> > Hi.
> > 
> > On Sat, Sep 04, 2021 at 02:40:13PM +0200, sp...@caiway.net wrote:
> > > Suddenly I can no longer reboot or poweroff my up-to-date
> > > bullseye system:
> > > 
> > > # reboot
> > > /usr/sbin/reboot: disabled in systemd-nspawn container
> > 
> > Unless I'm mistaken, these messages are not generated by systemd.
> > In fact, there's nothing that resembles such messages in systemd
> > sources.
> > 
> > So, try this, for starters:
> > 
> > /bin/systemd reboot
> > 
> 
> # /bin/systemd reboot
> Excess arguments.

Er, I meant /bin/systemctl reboot.
But anyway,

> > file /sbin/reboot
> 
> # file /sbin/reboot
> /sbin/reboot: POSIX shell script, ASCII text executable

That's not how it's supposed to be.
Somehow these shell scripts replaced actual halt, reboot and poweroff.

My suggestion:

ln -sf /bin/systemctl /sbin/reboot
ln -sf /bin/systemctl /sbin/halt
ln -sf /bin/systemctl /sbin/poweroff

Or, even better:

apt install --reinstall systemd-sysv

Reco

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[sp...@caiway.net]

On Sat, 4 Sep 2021 16:42:45 +0300
Reco  wrote:

>   Hi.

> /bin/systemd reboot
> 
> And, what about these:
> 
> ls -al /sbin/reboot
> file /sbin/reboot
> 
> Reco
> 

the commands poweroff and reboot are textfiles.
I have no idea

# mcedit /sbin/reboot:
#!/bin/sh

echo "${0}: disabled in systemd-nspawn container"

if [ -e /etc/open-infrastructure/container/shutdown.txt ]
then
cat /etc/open-infrastructure/container/shutdown.txt
elif [ -e /usr/share/open-infrastructure/container/shutdown.txt ]
then
cat /usr/share/open-infrastructure/container/shutdown.txt
fi

exit 1

#eof

# mcedit /sbin/poweroff:
#!/bin/sh

echo "${0}: disabled in systemd-nspawn container"

if [ -e /etc/open-infrastructure/container/shutdown.txt ]
then
cat /etc/open-infrastructure/container/shutdown.txt
elif [ -e /usr/share/open-infrastructure/container/shutdown.txt ]
then
cat /usr/share/open-infrastructure/container/shutdown.txt
fi

exit 1



# cat /usr/share/open-infrastructure/container/shutdown.txt

Linux container share the kernel of the host system they are running on,
there is no need to reboot just the container.

However, please contact your system administrator to reboot this
container from the host system.

So the reason is found, now I have to find out who/what take over these
basic commands

I have no packages with open-infrastructure installed

tia

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[sp...@caiway.net]

On Sat, 4 Sep 2021 16:42:45 +0300
Reco  wrote:

>   Hi.
> 
> On Sat, Sep 04, 2021 at 02:40:13PM +0200, sp...@caiway.net wrote:
> > Suddenly I can no longer reboot or poweroff my up-to-date
> > bullseye system:
> > 
> > # reboot
> > /usr/sbin/reboot: disabled in systemd-nspawn container
> 
> Unless I'm mistaken, these messages are not generated by systemd.
> In fact, there's nothing that resembles such messages in systemd
> sources.
> 
> So, try this, for starters:
> 
> /bin/systemd reboot
> 

# /bin/systemd reboot
Excess arguments.

> And, what about these:
> 
> ls -al /sbin/reboot

# ls -al /sbin/reboot
-rwxr-xr-x 1 root root 319 Mar 24 05:22 /sbin/reboot


> file /sbin/reboot
> 

# file /sbin/reboot
/sbin/reboot: POSIX shell script, ASCII text executable

> Reco
> 

thx

Re: /usr/sbin/reboot: disabled in systemd-nspawn container

[Reco]

Hi.

On Sat, Sep 04, 2021 at 02:40:13PM +0200, sp...@caiway.net wrote:
> Suddenly I can no longer reboot or poweroff my up-to-date
> bullseye system:
> 
> # reboot
> /usr/sbin/reboot: disabled in systemd-nspawn container

Unless I'm mistaken, these messages are not generated by systemd.
In fact, there's nothing that resembles such messages in systemd
sources.

So, try this, for starters:

/bin/systemd reboot

And, what about these:

ls -al /sbin/reboot
file /sbin/reboot

Reco

/usr/sbin/reboot: disabled in systemd-nspawn container

[sp...@caiway.net]

Hi,

Suddenly I can no longer reboot or poweroff my up-to-date
bullseye system:

# reboot
/usr/sbin/reboot: disabled in systemd-nspawn container

Linux container share the kernel of the host system they are running on,
there is no need to reboot just the container.

However, please contact your system administrator to reboot this
container from the host system.



# poweroff
/usr/sbin/poweroff: disabled in systemd-nspawn container

Linux container share the kernel of the host system they are running on,
there is no need to reboot just the container.

However, please contact your system administrator to reboot this
container from the host system.



I am definitively NOT in a container.

I did experiment with systemd-nspawn some weeks ago and stopped using
it.
I did often reboot/poweroff this system after this, and I have no idea
where to look for the bug.

# apt purge systemd-container does not help


Now I do Alt+SysReq+...to reboot/poweroff




tia

Re: Sid: /sbin/ifenslave missing??

[Sven Hartge]

Sven Hartge  wrote:

> Temporary solution: downgrade to 2.9 again, hold the package and monitor
> the bug report I linked.

Sorry, the correct bug is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959236

Unfortunately it has only "normal" severity, "grave" would be better
here, since it not only breaks the function of the package, it breaks
the whole system.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Sid: /sbin/ifenslave missing??

[Sven Hartge]

Grzesiek Sójka  wrote:
> On 5/17/20 12:34 PM, Sven Hartge wrote:

>> Mind doing a "ifup -v bond0" to really see what is called how and where
>> it fails in what way?

> after "ifup -v bond0" I get a larg number of following messages 
> (probably 1000?):

> + [ -n  ]
> + return 0
> + setup_master
> + add_master
> + [ -f /sys/class/net/bond0/bonding/slaves ]
> + return
> + early_setup_master
> + sysfs fail_over_mac
> + [ -n  ]
> + return 0
> + setup_master
> + add_master
> + [ -f /sys/class/net/bond0/bonding/slaves ]
> + return
> + early_setup_master
> + sysfs fail_over_mac
> /etc/network/if-pre-up.d/ifenslave: 67: Maximum function recursion depth 
> (1000) reached
> run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 2
> ifup: failed to bring up bond0

Interesting. Yes, this seems like a genuine bug in the package but not
caused by the removal of the ifenslave shell script but by some bug in
the ifup-(pre)scripts provided by the package.

Temporary solution: downgrade to 2.9 again, hold the package and monitor
the bug report I linked.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Sid: /sbin/ifenslave missing??

[Grzesiek Sójka]

On 5/17/20 12:34 PM, Sven Hartge wrote:

Mind doing a "ifup -v bond0" to really see what is called how and where
it fails in what way?


after "ifup -v bond0" I get a larg number of following messages 
(probably 1000?):


+ [ -n  ]
+ return 0
+ setup_master
+ add_master
+ [ -f /sys/class/net/bond0/bonding/slaves ]
+ return
+ early_setup_master
+ sysfs fail_over_mac
+ [ -n  ]
+ return 0
+ setup_master
+ add_master
+ [ -f /sys/class/net/bond0/bonding/slaves ]
+ return
+ early_setup_master
+ sysfs fail_over_mac
/etc/network/if-pre-up.d/ifenslave: 67: Maximum function recursion depth 
(1000) reached

run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 2
ifup: failed to bring up bond0

BTW: # apt-list | grep ifup
ifupdown/unstable,now 0.8.35+b1 amd64 [installed]

Re: Sid: /sbin/ifenslave missing??

[Sven Hartge]

Grzesiek Sójka  wrote:
> On 5/17/20 12:13 PM, Sven Hartge wrote:

>> How does your /etc/network/interfaces look like? Usally all the work is
>> done via if-pre-up.d and if-up.d scripts provided by the ifenslave
>> package.

> # cat /etc/network/interfaces
> source-directory /etc/network/interfaces.d
> auto bond0

> iface bond0 inet static
>   address 192.168.0.130
>   netmask 255.255.255.252
>   gateway 192.168.0.129
>   slaves eth0 eth1
>   mtu 9000

> So I need to "adjust" network configuration to bond using iproute2 instead?

No, that should work, my configurations look similar (but they are all
on Buster and thus on 2.9, so I have not seen this bug myself).

Mind doing a "ifup -v bond0" to really see what is called how and where
it fails in what way?

Grüße,
Sven.


-- 
Sigmentation fault. Core dumped.

Re: Sid: /sbin/ifenslave missing??

[Grzesiek Sójka]

On 5/17/20 12:13 PM, Sven Hartge wrote:

How does your /etc/network/interfaces look like? Usally all the work is
done via if-pre-up.d and if-up.d scripts provided by the ifenslave
package.


# cat /etc/network/interfaces
source-directory /etc/network/interfaces.d
auto bond0

iface bond0 inet static
  address 192.168.0.130
  netmask 255.255.255.252
  gateway 192.168.0.129
  slaves eth0 eth1
  mtu 9000

So I need to "adjust" network configuration to bond using iproute2 instead?

Re: Sid: /sbin/ifenslave missing??

[Sven Joachim]

On 2020-05-17 11:27 +0200, Grzesiek Sójka wrote:

> After upgrading ifenslave from 2.9 to 2.10 i found that there if no
> /sbin/ifenslave binary. To restore network connectivity I had to 
> manually downgrade to 2.9. Is it on purpose? If so, then how to
> properly configure link aggregation?

I don't use ifenslave, but this change has been done on purpose:

,
| ifenslave (2.10) unstable; urgency=medium
| [...]
|   * Remove the ifenslave binary, use iproute2 instead.
| [...]
|  -- Guus Sliepen   Sun, 26 Apr 2020 21:09:15 +0200
`

Refer to ip(8) and the manpages it references, if you can comprehend
them.

Cheers,
   Sven

Re: Sid: /sbin/ifenslave missing??

[Sven Hartge]

Grzesiek Sójka  wrote:

> After upgrading ifenslave from 2.9 to 2.10 i found that there if no
> /sbin/ifenslave binary. To restore network connectivity I had to
> manually downgrade to 2.9. Is it on purpose? If so, then how to
> properly configure link aggregation?

It seems you hit
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959075

But NEWS.Debian says:

,
| ifenslave (2.10) UNRELEASED; urgency=medium
|
|   This version of the ifenslave package no longer provides /sbin/ifenslave. 
The
|   /sbin/ip command from the iproute2 package supports creating bonding masters
|   and enslaving other interfaces to it.
|
|  -- Guus Sliepen   Tue, 08 May 2018 22:47:07 +0200
`

How does your /etc/network/interfaces look like? Usally all the work is
done via if-pre-up.d and if-up.d scripts provided by the ifenslave
package.

S!

-- 
Sigmentation fault. Core dumped.

Sid: /sbin/ifenslave missing??

[Grzesiek Sójka]

Hi there,

After upgrading ifenslave from 2.9 to 2.10 i found that there if no 
/sbin/ifenslave binary. To restore network connectivity I had to 
manually downgrade to 2.9. Is it on purpose? If so, then how to properly 
configure link aggregation?


Thank for any help in advance
Greg

Re: Re: Issue with OpenVPN inside a LXC container: Failed at step NAMESPACE spawning /usr/sbin/openvpn: Permission denied

[Simon Bernier St-Pierre]

Thanks a ton!

I'm running this container on my private network behind a NAT, so I'm 
not too worried about disabling apparmor. I ended up just giving as 
loose of a configuration I could and it did the trick.


lxc.apparmor.profile = unconfined
lxc.apparmor.allow_nesting = 1
lxc.apparmor.allow_incomplete = 1

The first line alone did not seem to do the trick, so I added 2 and 3 
and it worked. Good enough for me.


Thanks again!

Re: Issue with OpenVPN inside a LXC container: Failed at step NAMESPACE spawning /usr/sbin/openvpn: Permission denied

[Reco]

Hi.

On Tue, Jul 16, 2019 at 10:57:06PM -0400, Simon Bernier St-Pierre wrote:
> I have a LXC container which is connected to a remote VPN using
> OpenVPN. After upgrading to buster, the VPN does not start anymore.
> I'm using Debian buster on my host OS

These are relevant to the problem.

> This is the journalctl log for the openvpn service:
...
> Jul 16 20:32:30 dl systemd[70]: openvpn-client@pia.service: Failed to
> set up mount namespacing: Permission denied

And that is too.
As usual with this kind of problems, journalctl log is useless. What you
need is auditd log, because...

The most probable reasons of this are ProtectSystem=true in openvpn's
systemd unit (so systemd tries to setup a separate mount namespace for a
process), and an LXC Apparmor policy that started to work in buster (it
did not in stretch).

So, you have three options:

1) Set lxc.apparmor.profile = lxc-container-default-with-nesting for
your container. It may or may not help.

2) Disable Apparmor for LXC altogether (bad idea):
lxc.apparmor.profile = unconfined

3) Execute aa-logprof ("apparmor-utils" package) and stare into that
abyss.

Reco

Issue with OpenVPN inside a LXC container: Failed at step NAMESPACE spawning /usr/sbin/openvpn: Permission denied

[Simon Bernier St-Pierre]

I have a LXC container which is connected to a remote VPN using OpenVPN. 
After upgrading to buster, the VPN does not start anymore.


I'm using Debian buster on my host OS and Debian buster on the guest OS. 
Both were updated from stretch. Aside from OpenVPN there's only deluged 
and deluge-web that are installed.


This is the journalctl log for the openvpn service:

root@dl:/# journalctl -u openvpn-client@pia.service
-- Logs begin at Tue 2019-07-16 20:32:30 EDT, end at Tue 2019-07-16 
22:31:19 EDT. --

Jul 16 20:32:30 dl systemd[1]: Starting OpenVPN tunnel for pia...
Jul 16 20:32:30 dl systemd[70]: openvpn-client@pia.service: Failed to 
set up mount namespacing: Permission denied
Jul 16 20:32:30 dl systemd[70]: openvpn-client@pia.service: Failed at 
step NAMESPACE spawning /usr/sbin/openvpn: Permission denied
Jul 16 20:32:30 dl systemd[1]: openvpn-client@pia.service: Main process 
exited, code=exited, status=226/NAMESPACE
Jul 16 20:32:30 dl systemd[1]: openvpn-client@pia.service: Failed with 
result 'exit-code'.

Jul 16 20:32:30 dl systemd[1]: Failed to start OpenVPN tunnel for pia.

I've searched online but I haven't found anything relevant to my situation.

Anything to help me figure this one out will be greatly appreciated. Thanks!

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Andrei POPESCU]

On Vi, 31 mai 19, 08:51:20, Greg Wooledge wrote:
> On Fri, May 31, 2019 at 11:47:26AM +0200, Pascal Hambourg wrote:
> > > https://wiki.debian.org/MergedUsr
> > 
> > The wiki says this page does not exist yet.
> 
> It's actually .
 
Right, thanks (again) Greg for correcting my mistakes.

My current setup doesn't allow for easy copy-pasting so I wrote that by 
hand and misremembered it :(

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Andy Smith]

Hello,

On Fri, May 31, 2019 at 08:48:36AM -0500, Jason wrote:
> On Wed, May 29, 2019 at 11:46:50PM +, Andy Smith wrote:
> > How did you install this system?

[…]

> > One other person in this thread said they used (a script which
> > ultimately uses) debootstrap.
> 
> This system was installed on an SBC (similar to RPi) from a zipped 
> filesystem image, dd'd to the onboard eMMC chip.

It sounds likely that something in that process failed to copy
across file capabilities. As previously mentioned, some care has to
be used with tar for example, if you want to (re)store these. So
that's something to be aware of I guess…

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Jason]

On Wed, May 29, 2019 at 11:46:50PM +, Andy Smith wrote:
> Hi Jason,
> 
> On Wed, May 29, 2019 at 04:18:51PM -0500, Jason wrote:
> > On Mon, May 27, 2019 at 08:12:32AM +0300, Andrei POPESCU wrote:
> > > While I didn't mention it in this thread, ping had indeed somehow lost 
> > > its capabilities on my system. 'dpkg-reconfigure iputils-ping' fixed it.
> > 
> > That worked for me (I'm not the OP) with Stretch on an ARM board. Before 
> > running the above command, I could only ping as root or using sudo, now 
> > I can ping as a normal user. Thanks!
> 
> How did you install this system? Because /bin/ping is supposed to
> come with file capabilities such that the user can allow it to do
> what it needs to do (this is part of what 'dpkg-reconfigure
> iputils-ping' restores). So it would be interesting to know how the
> system was installed in case there is a general theme for those who
> never got those capabilities.
> 
> One other person in this thread said they used (a script which
> ultimately uses) debootstrap.

This system was installed on an SBC (similar to RPi) from a zipped 
filesystem image, dd'd to the onboard eMMC chip.

Thanks,
-- 
Jason

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Greg Wooledge]

On Fri, May 31, 2019 at 11:47:26AM +0200, Pascal Hambourg wrote:
> > https://wiki.debian.org/MergedUsr
> 
> The wiki says this page does not exist yet.

It's actually .

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Thomas Schmitt]

Hi,

i wrote:
> > Currently the Default User depends on assumptions about local package
> > management which are not obviously related to security.
> > That's a future pitfall which just needs its unintentional cover removed.

Reco wrote:
> The way I see it, the "problematic" package got that Important priority
> already. A potential pitfall is closed.

The priority in debian/control (and thus .dsc) is scheduled on salsa to be
lowered to "optional" by the next package release.

Whatever, the priority is not the problem with security. The lack of
dependency of iputils-ping on libcap2-bin is the problem.
This lack was justified by policy as of 2016. Soon later the priority of
libcap2-bin was raised to "important", but iputils-ping never made use of
this move.


> Replacing a working fallback mechanism with one-size-fits-all "everyone
> are using ext4 on amd64 and Linux" is hardly an improvement.

The proposal in the bug report would not disable the fallback mechanism
for situations where it is needed. It would only make sure that capable
kernels and filesystems would be able use upstream improvements of iptools.

The installation code in
  
https://sources.debian.org/src/iputils/3:20180629-2/debian/iputils-ping.postinst
adapts itself to effective success of an attempt to set capabilities:

if command -v setcap > /dev/null; then
if setcap cap_net_raw+ep /bin/ping; then
chmod u-s /bin/ping
else
echo "Setcap failed on /bin/ping, falling back to setuid" >&2
chmod u+s /bin/ping
fi
else
echo "Setcap is not installed, falling back to setuid" >&2
chmod u+s /bin/ping
fi

Safe for Default Users.

My best theory for the problem reported in bug 780721 that a normal user
cannot ping, is that setuid was disabled by mount -o nosuid or -o owner
and that setcap did not work because of his sparse installation.


Have a nice day :)

Thomas

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Reco]

On Fri, May 31, 2019 at 12:09:19PM +0200, Thomas Schmitt wrote:
> > Not every filesystem supported by Debian
> > implements extended attributes needed for capabilities.
> > Off the top of my head it's NFS and JFFS2.
> 
> It is about the filesystem which holds the /bin directory. I would deem it
> extra-expert to use a partly incapable filesystem for that.

Please. NFS-for-root is decades old. JFFS2 is wildly popular for DIY solutions.
Calling everyone who bought $20 ARM board on AliExpress an 'expert'
seems overstretched.


> Whatever, the maintainer's reasoning was a then valid quote from the
> policy manual
...
> It became not a decisive argument against dependency.

It's really sad to see a maintainer who resorts to lawyering instead of
considering real technical limitations of the "solution" proposed.


> > Upgrading this particular dependency leads
> > only to a dependency bloat, and Default Users™ (i.e. ones that are
> > installing Recommends by default) aren't affected anyway.
> 
> Currently the Default User depends on assumptions about local package
> management which are not obviously related to security.

So? The end result justifies a current situation.


> That's a future pitfall which just needs its unintentional cover removed.

The way I see it, the "problematic" package got that Important priority
already. A potential pitfall is closed.


> To skip a security improvement in order to save 111 kB of installed size
> seems daring. (Size for amd64 taken from end of
>   https://packages.debian.org/unstable/libcap2-bin
> )

Replacing a working fallback mechanism with one-size-fits-all "everyone
are using ext4 on amd64 and Linux" is hardly an improvement.

Reco

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Thomas Schmitt]

Hi,

i wrote:
> > "d/control: Drop Priority of libcap2"
> > https://salsa.debian.org/debian/libcap2/commit/5386335db24bfff5cc85bda69dbcda6ab2d7d20d

Reco wrote:
> Ah, that's what is was. That change made into the stable, I've just checked.

Not according to the package tracker:

oldstable has 1:2.24-8 of march 2015, i.e. before bug 780721.
  https://tracker.debian.org/media/packages/libc/libcap2/control-1%3A2.24-8
No particular Priority set on lbibcap2-bin

stable has 1:2.25-1 of october 2017, i.e. after bug 780721 went to sleep.
  https://tracker.debian.org/media/packages/libc/libcap2/control-1%3A2.25-1
libcap2-bin gets "Priority: important".

testing has 1:2.25-2 of february 2019.
  https://tracker.debian.org/media/packages/libc/libcap2/control-12.25-2
libcap2-bin still gets "Priority: important".
It was accepted in unstable at the very same day as the commit was made
which removed the particular Priority in the salsa git repo.
The package tracker's source browser says it is still in:
  https://sources.debian.org/src/libcap2/1:2.25-2/debian/control/#L17

But not to forget, the packages on the Debian mirrors get their priority
from the uploading procedure, not necessarily from the debian/control file
or the derived .dsc file.
All this forth and back might be independent of the maintainer of libcap2.


> Not every filesystem supported by Debian
> implements extended attributes needed for capabilities.
> Off the top of my head it's NFS and JFFS2.

It is about the filesystem which holds the /bin directory. I would deem it
extra-expert to use a partly incapable filesystem for that.

Whatever, the maintainer's reasoning was a then valid quote from the
policy manual

  "Packages must not depend on packages with lower priority values
   (excluding build-time dependencies). In order to ensure this, the
   priorities of one or more packages may need to be adjusted."

which is now replaced by a contrary statement

  "The priority of a package should
   not be increased merely because another higher-priority package depends
   on it; instead, the tools used to construct Debian installations will
   correctly handle package dependencies. In particular, this means that
   C-like libraries will almost never have a priority above optional [...]"

The issue of incapable systems was addressed in bug 780721 by maintainer:

  "The iputils-ping postinst script takes care to handle the case where
   setcap is either not available or not functional (due e.g. to running on
   a filesystem that doesn't support capabilities."

and bug reporter:

  "I'm aware we can't use capabilities on the non-Linux kernels yet, but
   since dpkg allows us to set dependencies per arch or per kernel, I don't
   see any particular problem adding libcap2-bin as to Depends for Linux."

It became not a decisive argument against dependency.


> Upgrading this particular dependency leads
> only to a dependency bloat, and Default Users™ (i.e. ones that are
> installing Recommends by default) aren't affected anyway.

Currently the Default User depends on assumptions about local package
management which are not obviously related to security. That's a future
pitfall which just needs its unintentional cover removed.

To skip a security improvement in order to save 111 kB of installed size
seems daring. (Size for amd64 taken from end of
  https://packages.debian.org/unstable/libcap2-bin
)
We can expect that the bug reporter, who is working on a colorful bunch
of elderly CPU arches, has a different idea of a Default User than us.
But shortage of memory and disk capacity surely belong to his considerations.


Have a nice day :)

Thomas

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Pascal Hambourg]

Le 31/05/2019 à 08:38, Andrei POPESCU a écrit :

On Mi, 29 mai 19, 23:29:21, Gene Heskett wrote:


the default $PATH the installer sets up for $users, apparently does not
include any of the sbin's, only /usr/bin and /bin. I've been fixing that
for several generations of debian installs.


It won't be necessary if you switch to merged /usr.


AFAIK, the /usr merge does not merge sbin and bin together.


https://wiki.debian.org/MergedUsr


The wiki says this page does not exist yet.

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Reco]

Hi.

On Fri, May 31, 2019 at 09:08:55AM +0200, Thomas Schmitt wrote:
> Andrei POPESCU wrote:
> > The other way would be if the archive priority was changed between
> > different installs.
> 
> This has happened in april 2016 (maybe related to bug 780721 ?)
> 
>   "d/control: Increase Priority of libcap2{,-bin} to important"
>   
> https://salsa.debian.org/debian/libcap2/commit/a3f0fbccfa946b6895da1b3521849d04ccf8da0f
> 
> and again four months ago
> 
>   "d/control: Drop Priority of libcap2"
>   
> https://salsa.debian.org/debian/libcap2/commit/5386335db24bfff5cc85bda69dbcda6ab2d7d20d
> 
> (The latter is not yet in the released package's control file.)
> 
> So one maintainer already adapted to the new policy rules.

Ah, that's what is was. That change made into the stable, I've just checked.


> But
>   https://salsa.debian.org/debian/iputils/raw/master/debian/control
> still has the hunchbacked gesture of recommending an actually necessary
> dependency:

No, maintainer is correct. Not every filesystem supported by Debian
implements extended attributes needed for capabilities. Off the top of
my head it's NFS and JFFS2. Upgrading this particular dependency leads
only to a dependency bloat, and Default Users™ (i.e. ones that are
installing Recommends by default) aren't affected anyway.

Reco

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Thomas Schmitt]

Hi,

Andrei POPESCU wrote:
> The other way would be if the archive priority was changed between
> different installs.

This has happened in april 2016 (maybe related to bug 780721 ?)

  "d/control: Increase Priority of libcap2{,-bin} to important"
  
https://salsa.debian.org/debian/libcap2/commit/a3f0fbccfa946b6895da1b3521849d04ccf8da0f

and again four months ago

  "d/control: Drop Priority of libcap2"
  
https://salsa.debian.org/debian/libcap2/commit/5386335db24bfff5cc85bda69dbcda6ab2d7d20d

(The latter is not yet in the released package's control file.)

So one maintainer already adapted to the new policy rules.

But
  https://salsa.debian.org/debian/iputils/raw/master/debian/control
still has the hunchbacked gesture of recommending an actually necessary
dependency:

  Package: iputils-ping
  ...
  Recommends: libcap2-bin
  ...
  Package: iputils-arping
  ...
  Recommends: libcap2-bin

(I understand that this suffices if your local package management is set
 to automatically install recommendations.
 I also understand that there is a coarse workaround if libcap2 is missing.)

So bug 780721 is still valid and could now be fixed.


Have a nice day :)

Thomas

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Andrei POPESCU]

On Jo, 30 mai 19, 18:43:05, Reco wrote:
>   Hi.
> 
> On Thu, May 30, 2019 at 11:08:22AM -0400, Greg Wooledge wrote:
> > I asked on IRC, and got this answer:
> > 
> >   The archive (Packages) and individual .debs can disagree on Priority. It's
> >   mostly a field that has no meaning these days.
> > 
> > I'm not 100% sure how to interpret that.  Are different mirrors giving
> > out different Packages files with different Priority settings?
> 
> Now that you mention it - [1].
> A mirror can override a package priority, that's true.

This would suggest you can get different results depending on mirror 
used, which is not the case. The priority is set in the central archive, 
which is then mirrored.

> I don't know if http://ftp.debian.org/debian/indices/ is mirrored too,
> along with the usual Release files and *debs. It can explain this
> discrepancy if it's true.
>
> The question is - which Priority goes into the package database on
> package install? That one from the package itself, or the one from the
> mirror?

APT and debootstrap will definitely use the archive view on priorities 
when deciding which packages to download and install.

dpkg on the other hand is probably using the information inside the 
package (debian/control) for its database, but probably not much else.
 
This is the most obvious way one could end up with different results. 

The other way would be if the archive priority was changed between 
different installs.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Andrei POPESCU]

On Mi, 29 mai 19, 23:29:21, Gene Heskett wrote:
> 
> the default $PATH the installer sets up for $users, apparently does not 
> include any of the sbin's, only /usr/bin and /bin. I've been fixing that 
> for several generations of debian installs. Probably shouldn't as there  
> may be some good reason for it, but it is MY machine.

It won't be necessary if you switch to merged /usr.
https://wiki.debian.org/MergedUsr

This will be the default for new buster installs. Older installs can be 
switched with the package usrmerge.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Andy Smith]

Hello,

On Thu, May 30, 2019 at 09:08:38AM +0300, Reco wrote:
> Easy. You run debootstrap, set some --include options (which pull
> libcap2-bin by dependency), and then you tar the whole resulting
> filesystem.
> tar never understood file capabilities, so they are lost in the process.

Sure, tar is one of the example ways I mentioned before of how I've
seen this go wrong.

> debootstrap (no --variant) does install iputils-ping, but does not
> install libcap2-bin. Hence iputils-ping postinst script simply sets
> suid bit on /bin/ping as postinst cannot locate setcap.

Oh, that's interesting. I didn't think of the case where there is no
libcap2-bin. Still, these reporters aren't getting a suid bit
either, so I guess there must be something else going wrong. Not
debootstrap.

Cheers,
Andy

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Thomas Schmitt]

Hi,

i pointed to:
> > https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-
0-1
> > [...] Packages may now depend on packages with a lower priority. [...]

Curt wrote:
> So it seems the reason invoked above is no longer valid due to a change in
> policy.

It can be legally called a bug meanwhile, because
  https://tracker.debian.org/media/packages/i/iputils/control-320180629-2
has

  Standards-Version: 4.1.4

whereas the policy change was already in 4.0.1.


If somebody here feels able to test the policy compliant change of
"Depends:", then it would be worth to mail to
   780...@bugs.debian.org
and to point out that the change is overdue. Binary package iputils-arping
has the same Recommends as iputils-ping. So one should check whether
the reason is the same.

The policy also demands to change libcap2-bin priority to "optional".
Currently it is "important", which probably gets overridden by the repo
deciders.
  https://tracker.debian.org/media/packages/libc/libcap2/control-12.25-2
has
  Standards-Version: 4.3.0


So that would be two maintainers to convince ... YMMV.


Have a nice day :)

Thomas

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Curt]

On 2019-05-30, Thomas Schmitt  wrote:
>
> So the explanation in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721#10
>
>   iputils-ping, as priority "important", cannot declare a dependency on
>   libcap2-bin, which is priority "optional".
>
> is wrong and in direct contradiction to The Policy.

I think it would be more accurate to call the explanation *caduc* (or
*caduque*) perhaps. 

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721#20
> quotes exactly the above policy paragraph as
>
>   Packages must not depend on packages with lower priority values
>   (excluding build-time dependencies). In order to ensure this, the
>   priorities of one or more packages may need to be adjusted.
>
> which i cannot see there any more.
> The change probably happened in august 2017:
>
>   
> https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-0-1
>   2.5
>   [...] Packages may now depend on packages with a lower priority. [...]

So it seems the reason invoked above is no longer valid due to a change in 
policy.

> Last message in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721
> is of february 2016.
>
>
> So this bug could need an update and iputils-ping could now depend on
> libcap2-bin.
>
> As we see in
>   https://tracker.debian.org/media/packages/i/iputils/control-320180629-2
> it is not done yet:
>
>   Package: iputils-ping
>   ...
>   Recommends: libcap2-bin
>
>
> Have a nice day :)

Ditto.

> Thomas
>
>


-- 
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Reco]

Hi.

On Thu, May 30, 2019 at 11:08:22AM -0400, Greg Wooledge wrote:
> I asked on IRC, and got this answer:
> 
>   The archive (Packages) and individual .debs can disagree on Priority. It's
>   mostly a field that has no meaning these days.
> 
> I'm not 100% sure how to interpret that.  Are different mirrors giving
> out different Packages files with different Priority settings?

Now that you mention it - [1].
A mirror can override a package priority, that's true.
I don't know if http://ftp.debian.org/debian/indices/ is mirrored too,
along with the usual Release files and *debs. It can explain this
discrepancy if it's true.

The question is - which Priority goes into the package database on
package install? That one from the package itself, or the one from the
mirror?


> Someone who's affected by the missing capabilities on ping might want
> to investigate more closely, or add some info to bug #780721.  Adrian
> talked about libcap2-bin being changed to "Priotity: important" at some
> point in the future (relative to 2016), so maybe that has already happened.

It sure did not happen here.


> I'm not sure how to *find out* whether that has happened, since we can't
> even figure out how to view the actual Priority.  Or, if the Priority
> "mostly ... has no meaning", then whatever was stopping Adrian from acting
> in 2016 might no longer be a roadblock.

In the context of the original deboostrap behaviour - it's simple.
debootstrap installs barebones to produce a working apt, and uses it to
install the rest of the packages.

apt trusts the mirror (it would be counterproductive to download and
analyze every package just to extract their Priority and Depends), hence
mirror's priority wins here.

Reco

[1] https://wiki.debian.org/FtpMaster/Override

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Thomas Schmitt]

Hi,

Curt wrote:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721
> >> (libcap2-bin is recommended but is not a dependancy of iputils-ping,
> >> because "iputils-ping, as priority 'important', cannot declare a
> >> dependency on libcap2-bin, which is priority 'optional'").

> Why is my Stretch apt-cache command telling me it's priority optional?
> Or am I once again missing some essential thing?

The statement in bug 780721 seems to be outdated. The priority
rules have been changed since then. The package maintainer does not
have the last say on this, anyways.



https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control

  Section and priority are used by front-ends like aptitude when they
  sort packages and select defaults. Once you upload the package to Debian,
  the value of these two fields can be overridden by the archive
  maintainers, in which case you will be notified by email.

https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

  The priority of a package is determined solely by the functionality
  it provides directly to the user. The priority of a package should
  not be increased merely because another higher-priority package depends
  on it; instead, the tools used to construct Debian installations will
  correctly handle package dependencies. In particular, this means that
  C-like libraries will almost never have a priority above optional,
  since they do not provide functionality directly to users. However,
  as an exception, the maintainers of Debian installers may request an
  increase of the priority of a package to resolve installation issues
  and ensure that the correct set of packages is included in a standard
  or minimal install.



So the explanation in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721#10

  iputils-ping, as priority "important", cannot declare a dependency on
  libcap2-bin, which is priority "optional".

is wrong and in direct contradiction to The Policy.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721#20
quotes exactly the above policy paragraph as

  Packages must not depend on packages with lower priority values
  (excluding build-time dependencies). In order to ensure this, the
  priorities of one or more packages may need to be adjusted.

which i cannot see there any more.
The change probably happened in august 2017:

  
https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-0-1
  2.5
  [...] Packages may now depend on packages with a lower priority. [...]

Last message in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721
is of february 2016.


So this bug could need an update and iputils-ping could now depend on
libcap2-bin.

As we see in
  https://tracker.debian.org/media/packages/i/iputils/control-320180629-2
it is not done yet:

  Package: iputils-ping
  ...
  Recommends: libcap2-bin


Have a nice day :)

Thomas

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Greg Wooledge]

I asked on IRC, and got this answer:

  The archive (Packages) and individual .debs can disagree on Priority. It's
  mostly a field that has no meaning these days.

I'm not 100% sure how to interpret that.  Are different mirrors giving
out different Packages files with different Priority settings?

Someone who's affected by the missing capabilities on ping might want
to investigate more closely, or add some info to bug #780721.  Adrian
talked about libcap2-bin being changed to "Priotity: important" at some
point in the future (relative to 2016), so maybe that has already happened.
I'm not sure how to *find out* whether that has happened, since we can't
even figure out how to view the actual Priority.  Or, if the Priority
"mostly ... has no meaning", then whatever was stopping Adrian from acting
in 2016 might no longer be a roadblock.

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Reco]

Hi.

On Thu, May 30, 2019 at 10:26:29AM -0400, Greg Wooledge wrote:
> On Thu, May 30, 2019 at 05:19:49PM +0300, Reco wrote:
> > "dpkg -s" gets package state from /var/lib/dpkg/status.
> > "apt-cache" also uses /var/lib/apt/lists/*.
> > 
> > Basically your result tells that libcap2-bin is "optional" from the
> > repository POV, but your local package database thinks it's "important".
> > 
> > And in this case I trust the repository and have to assume that your
> > local package database is somehow corrupt.
> 
> arc3:~$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status
> Package: libcap2-bin
> Status: install ok installed
> Priority: important
> 
> wooledg:~$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status
> Package: libcap2-bin
> Status: install ok installed
> Priority: important
> 
> wooledg:~$ ssh root@megview5 "grep -A2 'Package: libcap2-bin' 
> /var/lib/dpkg/status"
> root@megview5's password: 
> Package: libcap2-bin
> Status: install ok installed
> Priority: important
> 
> wooledg:~$ ssh svr4 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status"
> wooledg@svr4's password: 
> Package: libcap2-bin
> Status: install ok installed
> Priority: important
> 
> oledg:~$ ssh meglin2 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status"
> wooledg@meglin2's password: 
> Package: libcap2-bin
> Status: install ok installed
> Priority: optional
> 
> meglin2 is jessie.  wooledg is buster.  The others are stretch.

Yep. But for me it's (stretch):

$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status
Package: libcap2-bin
Status: install ok installed
Priority: optional

Reco

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Greg Wooledge]

On Thu, May 30, 2019 at 05:19:49PM +0300, Reco wrote:
> "dpkg -s" gets package state from /var/lib/dpkg/status.
> "apt-cache" also uses /var/lib/apt/lists/*.
> 
> Basically your result tells that libcap2-bin is "optional" from the
> repository POV, but your local package database thinks it's "important".
> 
> And in this case I trust the repository and have to assume that your
> local package database is somehow corrupt.

arc3:~$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status
Package: libcap2-bin
Status: install ok installed
Priority: important

wooledg:~$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status
Package: libcap2-bin
Status: install ok installed
Priority: important

wooledg:~$ ssh root@megview5 "grep -A2 'Package: libcap2-bin' 
/var/lib/dpkg/status"
root@megview5's password: 
Package: libcap2-bin
Status: install ok installed
Priority: important

wooledg:~$ ssh svr4 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status"
wooledg@svr4's password: 
Package: libcap2-bin
Status: install ok installed
Priority: important

oledg:~$ ssh meglin2 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status"
wooledg@meglin2's password: 
Package: libcap2-bin
Status: install ok installed
Priority: optional

meglin2 is jessie.  wooledg is buster.  The others are stretch.

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Reco]

Hi.

On Thu, May 30, 2019 at 09:10:55AM -0400, Greg Wooledge wrote:
> On Thu, May 30, 2019 at 01:00:19PM -, Curt wrote:
> > On 2019-05-30, Greg Wooledge  wrote:
> > > But libcap2-bin is priority important in both stretch and buster.
> > 
> > Why is my Stretch apt-cache command telling me it's priority optional?
> > Or am I once again missing some essential thing?
> 
> Uh...
> 
> arc3:~$ dpkg -s libcap2-bin | grep -i priority
> Priority: important
> arc3:~$ apt-cache show libcap2-bin | grep -i priority
> Priority: optional

Both show "optional" to me BTW.


> OK, I have no freaking idea what this means.

strace(1) to the rescue.
"dpkg -s" gets package state from /var/lib/dpkg/status.
"apt-cache" also uses /var/lib/apt/lists/*.

Basically your result tells that libcap2-bin is "optional" from the
repository POV, but your local package database thinks it's "important".

And in this case I trust the repository and have to assume that your
local package database is somehow corrupt.

Reco

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Curt]

On 2019-05-30, Greg Wooledge  wrote:
> On Thu, May 30, 2019 at 01:00:19PM -, Curt wrote:
>> On 2019-05-30, Greg Wooledge  wrote:
>> > But libcap2-bin is priority important in both stretch and buster.
>> 
>> Why is my Stretch apt-cache command telling me it's priority optional?
>> Or am I once again missing some essential thing?
>
> Uh...
>
> arc3:~$ dpkg -s libcap2-bin | grep -i priority
> Priority: important
> arc3:~$ apt-cache show libcap2-bin | grep -i priority
> Priority: optional
>
> OK, I have no freaking idea what this means.
>
>

curty@einstein:~$ dpkg -s libcap2-bin | grep -i priority
Priority: optional

At least I'm optionally consistent.

;-)

-- 
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Greg Wooledge]

On Thu, May 30, 2019 at 01:00:19PM -, Curt wrote:
> On 2019-05-30, Greg Wooledge  wrote:
> > But libcap2-bin is priority important in both stretch and buster.
> 
> Why is my Stretch apt-cache command telling me it's priority optional?
> Or am I once again missing some essential thing?

Uh...

arc3:~$ dpkg -s libcap2-bin | grep -i priority
Priority: important
arc3:~$ apt-cache show libcap2-bin | grep -i priority
Priority: optional

OK, I have no freaking idea what this means.

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Curt]

On 2019-05-30, Greg Wooledge  wrote:
> On Thu, May 30, 2019 at 09:11:44AM -, Curt wrote:
>> There is a bug related to this imbroglio:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721
>> (libcap2-bin is recommended but is not a dependancy of iputils-ping,
>> because "iputils-ping, as priority 'important', cannot declare a
>> dependency on libcap2-bin, which is priority 'optional'").
>
> But libcap2-bin is priority important in both stretch and buster.
>
>

Why is my Stretch apt-cache command telling me it's priority optional?
Or am I once again missing some essential thing?

curty@einstein:~$ apt-cache show libcap2-bin 
Package: libcap2-bin
Source: libcap2
Version: 1:2.25-1
Installed-Size: 85
Maintainer: Christian Kastner 
Architecture: amd64
Replaces: libcap-bin
Depends: libc6 (>= 2.14), libcap2 (>= 1:2.10)
Recommends: libpam-cap
Breaks: libcap-bin
Description-en: POSIX 1003.1e capabilities (utilities)
 Libcap implements the user-space interfaces to the POSIX 1003.1e capabilities
 available in Linux kernels. These capabilities are a partitioning of the all
 powerful root privilege into a set of distinct privileges.
 .
 This package contains additional utilities.
Description-md5: f223f06c6e812dc45d4b21cbd8163d36
Multi-Arch: foreign
Homepage: http://sites.google.com/site/fullycapable/
Tag: admin::configuring, implemented-in::c, interface::commandline,
 role::program, scope::utility
Section: utils
Priority: optional
Filename: pool/main/libc/libcap2/libcap2-bin_2.25-1_amd64.deb
Size: 26490
MD5sum: cf46bb9dd77bd949226b90f735d52f33
SHA256: 8b6a70886d13a53e35bfacebab1bc869a09f405783f734835f313460e80be94e


-- 
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Greg Wooledge]

On Thu, May 30, 2019 at 09:11:44AM -, Curt wrote:
> There is a bug related to this imbroglio:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721
> (libcap2-bin is recommended but is not a dependancy of iputils-ping,
> because "iputils-ping, as priority 'important', cannot declare a
> dependency on libcap2-bin, which is priority 'optional'").

But libcap2-bin is priority important in both stretch and buster.

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Curt]

On 2019-05-29, Andy Smith  wrote:
>
> How did you install this system? Because /bin/ping is supposed to
> come with file capabilities such that the user can allow it to do
> what it needs to do (this is part of what 'dpkg-reconfigure
> iputils-ping' restores). So it would be interesting to know how the
> system was installed in case there is a general theme for those who
> never got those capabilities.

There is a bug related to this imbroglio:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721
(libcap2-bin is recommended but is not a dependancy of iputils-ping,
because "iputils-ping, as priority 'important', cannot declare a
dependency on libcap2-bin, which is priority 'optional'").

> One other person in this thread said they used (a script which
> ultimately uses) debootstrap.
>
> Cheers,
> Andy
>
>


-- 
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Reco]

Hi.

On Thu, May 30, 2019 at 02:44:58AM +, Andy Smith wrote:
> So my question is, are installs done by debootstrap somehow losing
> the file capabilities? I ask because in this thread, one of the
> other people reporting a /bin/ping without the correct capabilities
> did their install through debootstrap.

Easy. You run debootstrap, set some --include options (which pull
libcap2-bin by dependency), and then you tar the whole resulting
filesystem.
tar never understood file capabilities, so they are lost in the process.


> If you've just done a debootstrap, what does getcap return for the
> /bin/ping that got installed?

I'm not Cindy (obviously), but I'm not lazy, so I just run debootstrap a
couple of times.

debootstrap --variant=minbase does not install iputils-ping at all.

debootstrap (no --variant) does install iputils-ping, but does not
install libcap2-bin. Hence iputils-ping postinst script simply sets
suid bit on /bin/ping as postinst cannot locate setcap.

Reco

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Gene Heskett]

On Wednesday 29 May 2019 07:46:50 pm Andy Smith wrote:

> Hi Jason,
>
> On Wed, May 29, 2019 at 04:18:51PM -0500, Jason wrote:
> > On Mon, May 27, 2019 at 08:12:32AM +0300, Andrei POPESCU wrote:
> > > While I didn't mention it in this thread, ping had indeed somehow
> > > lost its capabilities on my system. 'dpkg-reconfigure
> > > iputils-ping' fixed it.
> >
> > That worked for me (I'm not the OP) with Stretch on an ARM board.
> > Before running the above command, I could only ping as root or using
> > sudo, now I can ping as a normal user. Thanks!
>
> How did you install this system? Because /bin/ping is supposed to
> come with file capabilities such that the user can allow it to do
> what it needs to do (this is part of what 'dpkg-reconfigure
> iputils-ping' restores). So it would be interesting to know how the
> system was installed in case there is a general theme for those who
> never got those capabilities.
>
> One other person in this thread said they used (a script which
> ultimately uses) debootstrap.
>
> Cheers,
> Andy

the default $PATH the installer sets up for $users, apparently does not 
include any of the sbin's, only /usr/bin and /bin. I've been fixing that 
for several generations of debian installs. Probably shouldn't as there  
may be some good reason for it, but it is MY machine.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Andy Smith]

Hi Cindy,

On Wed, May 29, 2019 at 09:48:44PM -0400, Cindy Sue Causey wrote:
> So, yeah, at least for Debootstrap. "iputils-ping" is in there at the
> absolute very first start where the Developers have picked the very
> first packages that get the party started before the User then picks
> everything else...

That's not the issue at hand. The issue is whether the file
/bin/ping retains the file capabilities. People who have a /bin/ping
that only works as root are missing these:

$ getcap /bin/ping
/bin/ping = cap_net_raw+ep

If they didn't have the package installed at all then it would be a
very different and more obvious error that was presented.

So my question is, are installs done by debootstrap somehow losing
the file capabilities? I ask because in this thread, one of the
other people reporting a /bin/ping without the correct capabilities
did their install through debootstrap.

If you've just done a debootstrap, what does getcap return for the
/bin/ping that got installed?

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Cindy Sue Causey]

On 5/29/19, Andy Smith  wrote:
> Hi Jason,
>
> On Wed, May 29, 2019 at 04:18:51PM -0500, Jason wrote:
>> On Mon, May 27, 2019 at 08:12:32AM +0300, Andrei POPESCU wrote:
>> > While I didn't mention it in this thread, ping had indeed somehow lost
>> > its capabilities on my system. 'dpkg-reconfigure iputils-ping' fixed
>> > it.
>>
>> That worked for me (I'm not the OP) with Stretch on an ARM board. Before
>> running the above command, I could only ping as root or using sudo, now
>> I can ping as a normal user. Thanks!
>
> How did you install this system? Because /bin/ping is supposed to
> come with file capabilities such that the user can allow it to do
> what it needs to do (this is part of what 'dpkg-reconfigure
> iputils-ping' restores). So it would be interesting to know how the
> system was installed in case there is a general theme for those who
> never got those capabilities.
>
> One other person in this thread said they used (a script which
> ultimately uses) debootstrap.


Was sitting here reading through before responding. Debootstrap. I
JUST seconds ago finished running the first step, the initial download
and install, for that again. *having to rebuild my dotDeb cache, don't
wanna talk about it, smacking my head!*

Just searched and "iputils-ping" is already installed at the absolute
bare minimum debootstrap base level. I really didn't think that
package was installed because I don't ever remember encountering that
package name. That "ping" part would stand out to me, but it never
has... until just now.

So, yeah, at least for Debootstrap. "iputils-ping" is in there at the
absolute very first start where the Developers have picked the very
first packages that get the party started before the User then picks
everything else...

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* Base system installed successfully. Works every time... as long
as... APT archives are not... cough.. symlinked instead of "mount -B".
*

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Andy Smith]

Hi Jason,

On Wed, May 29, 2019 at 04:18:51PM -0500, Jason wrote:
> On Mon, May 27, 2019 at 08:12:32AM +0300, Andrei POPESCU wrote:
> > While I didn't mention it in this thread, ping had indeed somehow lost 
> > its capabilities on my system. 'dpkg-reconfigure iputils-ping' fixed it.
> 
> That worked for me (I'm not the OP) with Stretch on an ARM board. Before 
> running the above command, I could only ping as root or using sudo, now 
> I can ping as a normal user. Thanks!

How did you install this system? Because /bin/ping is supposed to
come with file capabilities such that the user can allow it to do
what it needs to do (this is part of what 'dpkg-reconfigure
iputils-ping' restores). So it would be interesting to know how the
system was installed in case there is a general theme for those who
never got those capabilities.

One other person in this thread said they used (a script which
ultimately uses) debootstrap.

Cheers,
Andy

Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)

[Jason]

On Mon, May 27, 2019 at 08:12:32AM +0300, Andrei POPESCU wrote:
> 
> While I didn't mention it in this thread, ping had indeed somehow lost 
> its capabilities on my system. 'dpkg-reconfigure iputils-ping' fixed it.

That worked for me (I'm not the OP) with Stretch on an ARM board. Before 
running the above command, I could only ping as root or using sudo, now 
I can ping as a normal user. Thanks!

> 
> Kind regards,
> Andrei
> -- 
> http://wiki.debian.org/FAQsFromDebianUser


-- 
Jason

Re: Why /usr/sbin is not in my root $PATH ?

[Andy Smith]

Hello,

On Mon, May 27, 2019 at 08:12:32AM +0300, Andrei POPESCU wrote:
> On Lu, 27 mai 19, 02:15:49, Andy Smith wrote:
> > 
> > Glenn, and Andrei, do you do anything out of the ordinary to
> > install?
>  
> https://salsa.debian.org/amp-guest/pine64/blob/master/pine64_buildimage

Seems it does a debootstrap, so it would be interesting to know if a
plain old debootstrap results in a /bin/ping with the correct
capabilities…

Cheers,
Andy

Re: Why /usr/sbin is not in my root $PATH ?

[Andrei POPESCU]

On Lu, 27 mai 19, 02:15:49, Andy Smith wrote:
> 
> Glenn, and Andrei, do you do anything out of the ordinary to
> install?
 
https://salsa.debian.org/amp-guest/pine64/blob/master/pine64_buildimage

> Myself I have seen this happen when untarring the operating system
> as by default tar does not store or re-apply such capabilities.

While I didn't mention it in this thread, ping had indeed somehow lost 
its capabilities on my system. 'dpkg-reconfigure iputils-ping' fixed it.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Why /usr/sbin is not in my root $PATH ?

[Andy Smith]

Hello,

On Sun, May 26, 2019 at 07:41:41AM -0600, ghe wrote:
> On 2/21/19 11:12 AM, ghe wrote:
> 
> > Another Busterism, BTW: ping now requires root privileges. It does on my
> > computer, anyway. Maybe I made a mistake when I installed -- somebody
> > sure did.
> 
> Fix: 'alias ping="sudo ping"' in .bashrc. I'm on Buster too :-)

After a normal install, /bin/ping should end up with the
capabilities such that it can do what it needs to do. These are:

$ getcap /bin/ping
/bin/ping = cap_net_raw+ep

If yours has not ended up with those capabilities, I think that is a
bug in whatever method of install you have used.

Glenn, and Andrei, do you do anything out of the ordinary to
install?

Myself I have seen this happen when untarring the operating system
as by default tar does not store or re-apply such capabilities.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Why /usr/sbin is not in my root $PATH ?

[ghe]

On 2/21/19 11:12 AM, ghe wrote:

> Another Busterism, BTW: ping now requires root privileges. It does on my
> computer, anyway. Maybe I made a mistake when I installed -- somebody
> sure did.

Fix: 'alias ping="sudo ping"' in .bashrc. I'm on Buster too :-)

-- 
Glenn English

Re: Why /usr/sbin is not in my root $PATH ?

[Andrei POPESCU]

On Jo, 21 feb 19, 12:42:47, Greg Wooledge wrote:
> Well, for those who are interested, I've added some information to
> .  I'm trusting that the
> ALWAYS_SET_PATH thing from that random web page was actually correct,
> because verification would take a lot of work.  It's a wiki, so someone
> else can correct it if it's wrong.
> 
> When I linked to EnvironmentVariables I also found a section at the
> end of *that* page which describes the current behavior of su, so I
> updated that page slightly as well.
> 
> I can't even begin to guess how many places assume the current su
> behavior or how difficult it will be to find and change them all.

You have studied this issue in great detail.

Would you care to submit a bug against release-notes with proposed 
wording?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Why /usr/sbin is not in my root $PATH ?

[Andrei POPESCU]

On Jo, 21 feb 19, 11:26:29, Greg Wooledge wrote:
> On Thu, Feb 21, 2019 at 04:14:53PM +, Jonathan de Boyne Pollard wrote:
> > You could point them to StackExchange in the meantime.  (-:
> > 
> > * https://unix.stackexchange.com/a/460769/5132
> 
> On that page:
> > Doing plain 'su' is a really bad idea for many reasons,
> 
> Name one!  Seriously, what kind of inane statement is that?
> 
> > If you want to restore behaviour more similar to the previous one you can
> > add 'ALWAYS_SET_PATH yes' in /etc/login.defs.
> 
> OK, I'll just go to Debian's online man pages and find the buster
> man page for su (or login.defs) to find out what that is...
> 
> ... hey, where's the buster man pages?
 
Normally there are links for testing and unstable, but in this case the 
manpage is also in a different package:

https://manpages.debian.org/testing/util-linux/su.1.en.html

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: [OT] Re: Why /usr/sbin is not in my root $PATH ?

[David Wright]

On Sun 24 Feb 2019 at 17:28:18 (+), Martin Smith wrote:
> On 24/02/2019 15:39, David Wright wrote:
> > On Sun 24 Feb 2019 at 08:57:37 (-), Curt wrote:
> > > On 2019-02-24, Mart van de Wege  wrote:
> > > > Really, not using a clean, known environment as root is plain good
> > > > practice, and has been for years, if not actually decades.
> > > Have you expressed the opposite of your intention here?
> > Often accidentally done.
> > 
> > > A clean, known environment sounds like something in one of those Mormon
> > > pamphlets.
> > You mean somebody actually reads The Watchtower
> actually old chap thats the Jehovah's Witnesses scare sheet :)

QED.

Cheers,
David.

Re: [OT] Re: Why /usr/sbin is not in my root $PATH ?

[Martin Smith]

On 24/02/2019 15:39, David Wright wrote:

On Sun 24 Feb 2019 at 08:57:37 (-), Curt wrote:

On 2019-02-24, Mart van de Wege  wrote:

Really, not using a clean, known environment as root is plain good
practice, and has been for years, if not actually decades.

Have you expressed the opposite of your intention here?

Often accidentally done.


A clean, known environment sounds like something in one of those Mormon
pamphlets.

You mean somebody actually reads The Watchtower

actually old chap thats the Jehovah's Witnesses scare sheet :)


Cheers,
David.




--

Martin

[OT] Re: Why /usr/sbin is not in my root $PATH ?

[David Wright]

On Sun 24 Feb 2019 at 08:57:37 (-), Curt wrote:
> On 2019-02-24, Mart van de Wege  wrote:
> >
> > Really, not using a clean, known environment as root is plain good
> > practice, and has been for years, if not actually decades.
> 
> Have you expressed the opposite of your intention here?

Often accidentally done.

> A clean, known environment sounds like something in one of those Mormon
> pamphlets.

You mean somebody actually reads The Watchtower?

Cheers,
David.

Re: Why /usr/sbin is not in my root $PATH ?

[Curt]

On 2019-02-24, Mart van de Wege  wrote:
>
> Really, not using a clean, known environment as root is plain good
> practice, and has been for years, if not actually decades.

Have you expressed the opposite of your intention here?

A clean, known environment sounds like something in one of those Mormon
pamphlets.

;-)

> Mart
>


-- 
When you have fever you are heavy and light, you are small and swollen, you
climb endlessly a ladder which turns like a wheel. 
Jean Rhys, Voyage in the Dark

Re: Why /usr/sbin is not in my root $PATH ?

[Mart van de Wege]

John Hasler  writes:

>> But it's not Joe Random User, it's Joe Sysadmin
>
> Worse.  Who is most likely to have put weird stuff in his environment?

And it's not as if sysadmins never log in as other users. Oh no.

Really, not using a clean, known environment as root is plain good
practice, and has been for years, if not actually decades.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Why /usr/sbin is not in my root $PATH ?

[John Hasler]

> But it's not Joe Random User, it's Joe Sysadmin

Worse.  Who is most likely to have put weird stuff in his environment?
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Why /usr/sbin is not in my root $PATH ?

[Tixy]

On Sat, 2019-02-23 at 15:27 +0100, Mart van de Wege wrote:
> Greg Wooledge  writes:
> 
> > 
> > The problem with "su -" is that it strips out *all* of your
> > environment,
> 
> That's a feature, not a bug. You *don't* want to import Joe Random
> User's environment into root's.

But it's not Joe Random User, it's Joe Sysadmin - unless you're in the
habit of giving root's password to everyone.

-- 
Tixy

Re: Why /usr/sbin is not in my root $PATH ?

[Mart van de Wege]

Greg Wooledge  writes:

>
> The problem with "su -" is that it strips out *all* of your environment,

That's a feature, not a bug. You *don't* want to import Joe Random
User's environment into root's.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Why /usr/sbin is not in my root $PATH ?

[Ric Moore]

On 2/21/19 1:36 PM, ghe wrote:

On 2/21/19 11:18 AM, Reco wrote:


Ping *always* required root,


Maybe, but I didn't know that. I've been on Debian since the days of the
major Toy Story characters, and I've always just typed 'ping' and it punged.


I just typed "ping redhat.com", as user, and it pinged. But I couldn't 
get it to "pung". :) Ric

Re: Why /usr/sbin is not in my root $PATH ?

[ghe]

On 2/21/19 11:50 AM, Greg Wooledge wrote:

> It's possible that somehow you removed your /bin/ping and restored it from
> a backup, but you didn't re-run the thing that gives it the special
> capabilities it needs.  

Don't think so. Just a vanilla netinstall. Like always. I think.

> Or, who knows, maybe something else happened.

Something did :-) The shell, or something, talks about socket not being
accessible. Certainly reasonable/believable.

Thanks -- will fix...

-- 
Glenn English

Re: Why /usr/sbin is not in my root $PATH ?

[Greg Wooledge]

On Thu, Feb 21, 2019 at 11:36:44AM -0700, ghe wrote:
> On 2/21/19 11:18 AM, Reco wrote:
> 
> > Ping *always* required root, 
> 
> Maybe, but I didn't know that. I've been on Debian since the days of the
> major Toy Story characters, and I've always just typed 'ping' and it punged.
> 
> But thanks, somebodyAtDebian, for correcting my decades old expectation.

You might be confused here.  The ping program is intended to *work* for
all users, but in order to work, it needs a special capability.
Traditionally the ping program acquired this capability by being installed
with the setuid bit.  In more recent releases of Debian, /bin/ping is
no longer setuid, and instead uses the Linux capabilities feature
for its special power-up.

 is the
first link I found which explains this.  Seems like the right level of
exposition for this thread.

It's possible that somehow you removed your /bin/ping and restored it from
a backup, but you didn't re-run the thing that gives it the special
capabilities it needs.  Or, who knows, maybe something else happened.

Re: Why /usr/sbin is not in my root $PATH ?

[ghe]

On 2/21/19 11:18 AM, Reco wrote:

> Ping *always* required root, 

Maybe, but I didn't know that. I've been on Debian since the days of the
major Toy Story characters, and I've always just typed 'ping' and it punged.

But thanks, somebodyAtDebian, for correcting my decades old expectation.

-- 
Glenn English

Re: Why /usr/sbin is not in my root $PATH ?

[Reco]

Hi.

On Thu, Feb 21, 2019 at 11:12:12AM -0700, ghe wrote:
> Another Busterism, BTW: ping now requires root privileges. It does on
> my
> computer, anyway. Maybe I made a mistake when I installed -- somebody
> sure did.

Ping *always* required root, more precisely, CAP_NET_RAW.
So they either made ping root-owned suid, or assigned CAP_NET_RAW
capability to it (that's stretch btw):

$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep

So, run "/var/lib/dpkg/info/iputils-ping.postinst configure" (or whatever 
iputils
alternative you have installed), and enjoy sanity restored.


PS I should watch who I'm replying to.

Reco

Re: Why /usr/sbin is not in my root $PATH ?

[Reco]

Hi.

On Thu, Feb 21, 2019 at 11:12:12AM -0700, ghe wrote:
> Another Busterism, BTW: ping now requires root privileges. It does on
> my
> computer, anyway. Maybe I made a mistake when I installed -- somebody
> sure did.

Ping *always* required root, more precisely, CAP_NET_RAW.
So they either made ping root-owned suid, or assigned CAP_NET_RAW
capability to it (that's stretch btw):

$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep

So, run /var/lib/dpkg/info/iputils-ping.postinst (or whatever iputils
alternative you have installed), and enjoy sanity restored.

Reco

Re: Why /usr/sbin is not in my root $PATH ?

[ghe]

On 2/21/19 10:15 AM, Reco wrote:

> It's not the first time Debian project chose to do exactly the same
> others did for decades.

Can you say Ptolemy? He (and his followers) did exactly the same he did
for centuries.

Another Busterism, BTW: ping now requires root privileges. It does on my
computer, anyway. Maybe I made a mistake when I installed -- somebody
sure did.

The idea of putting sbin, etc. (and looking at who has execute) in my
user path is becoming more and more attractive.

Who needs Unix? OS360 and msdos and CP/M did the job for decades...

-- 
Glenn English

Re: Why /usr/sbin is not in my root $PATH ?

[Greg Wooledge]

Well, for those who are interested, I've added some information to
.  I'm trusting that the
ALWAYS_SET_PATH thing from that random web page was actually correct,
because verification would take a lot of work.  It's a wiki, so someone
else can correct it if it's wrong.

When I linked to EnvironmentVariables I also found a section at the
end of *that* page which describes the current behavior of su, so I
updated that page slightly as well.

I can't even begin to guess how many places assume the current su
behavior or how difficult it will be to find and change them all.

Re: Why /usr/sbin is not in my root $PATH ?

[Reco]

On Thu, Feb 21, 2019 at 11:26:29AM -0500, Greg Wooledge wrote:
> On Thu, Feb 21, 2019 at 04:14:53PM +, Jonathan de Boyne Pollard wrote:
> > You could point them to StackExchange in the meantime.  (-:
> > 
> > * https://unix.stackexchange.com/a/460769/5132
> 
> On that page:
> > Doing plain 'su' is a really bad idea for many reasons,
> 
> Name one!  Seriously, what kind of inane statement is that?

I have five reasons for you. They are called AIX, HP-UX, Solaris, RHEL
and busybox's su in no particular order.
It's not the first time Debian project chose to do exactly the same
others did for decades.


> > If you want to restore behaviour more similar to the previous one you can
> > add 'ALWAYS_SET_PATH yes' in /etc/login.defs.
> 
> OK, I'll just go to Debian's online man pages and find the buster
> man page for su (or login.defs) to find out what that is...
> 
> ... hey, where's the buster man pages?

Exactly there they belong. In .deb archives.

Reco

Re: Why /usr/sbin is not in my root $PATH ?

[Jonathan de Boyne Pollard]

Greg Wooledge:


At some point I'm going to need to write a wiki page to explain the 
change, and list some known workarounds, so that users can pick which 
one they want to implement.



You could point them to StackExchange in the meantime.  (-:

* https://unix.stackexchange.com/a/460769/5132

Re: Why /usr/sbin is not in my root $PATH ?

[Greg Wooledge]

On Thu, Feb 21, 2019 at 04:14:53PM +, Jonathan de Boyne Pollard wrote:
> You could point them to StackExchange in the meantime.  (-:
> 
> * https://unix.stackexchange.com/a/460769/5132

On that page:
> Doing plain 'su' is a really bad idea for many reasons,

Name one!  Seriously, what kind of inane statement is that?

> If you want to restore behaviour more similar to the previous one you can
> add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

OK, I'll just go to Debian's online man pages and find the buster
man page for su (or login.defs) to find out what that is...

... hey, where's the buster man pages?

Oh, lovely.  There aren't any.  So I'd have to extract the man page out 
of a buster .deb by hand, or actually RUN buster, to find out how to
document the changes in buster and how to work around them.

*sigh* ... it's going to be one of *those* upgrades, isn't it.