Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH
> > At this point, I think it'd be worth revisiting, at the project level, > the historical tradition of leaving the sbin directories out of non-root > paths. Setting aside all the single user desktop and laptop systems, > there are enough alternative ways to grant restricted root (file ACLs, > etc), and to run in alternate filesystem namespaces (e.g. containers), > that the functional distinctions that lead to the original directory > split are probably applicable in a minority of situations these days. I also agree we could here revisit the unix tradition ( which btw is not such a strong one anymore CentOS, and the BSDs have /usr/sbin and /sbin in path) However I also I agree that it should be done at the project level, not in the vagrant box or cloud image , so I will reassign this to the general pseudo-package.
Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH
Got it. Thanks a million! I learned a lot from your responses :) Jorge On Tue, 21 May 2019 at 05:46, Theodore Ts'o wrote: > On Mon, May 20, 2019 at 08:17:09PM -0700, Noah Meyerhans wrote: > > At this point, I think it'd be worth revisiting, at the project level, > > the historical tradition of leaving the sbin directories out of non-root > > paths. Setting aside all the single user desktop and laptop systems, > > there are enough alternative ways to grant restricted root (file ACLs, > > etc), and to run in alternate filesystem namespaces (e.g. containers), > > that the functional distinctions that lead to the original directory > > split are probably applicable in a minority of situations these days. > > Sure, and I often use /sbin/mke2fs on create file system images on > plain files and then corrupt them using /sbin/debugfs to create > regression tests for e2fsck, and I do all of this w/o being root. So > I have /sbin and /usr/sbin and /usr/local/sbin in my path. Along with > a whole bunch of other customizations in my dot files, of course. > > But my usage is an edge case, and asking Debian to make changes to > global changes to the defaults for people like me was never something > I thought was justifiable. Ultimately, if we believe that someday > we'll have the year of the Linux Desktop, where the primary > applications used by users are things like Firefox, Open Office, > Tuxracer, etc., adding /sbin and /usr/sbin might not be doing those > users a favor --- and those of us who are more technical are perfectly > capable of customizing our dot files. (Heck, I just pull a git repo > into ~/dotfiles, and then run "make install" and I get a custom set of > my dotfiles for that installation. :-) > > > This isn't something that I feel strongly about, though. Anybody who > > does should retitle this bug appropriately and reassign it to the > > 'general' pseudopackage, whereupon it can be discussed on debian-devel. > > Otherwise it should get tagged wontfix, unless someone thinks this is an > > appropriate change to introduce at the cloud image level (I would not > > agree with this). > > I agree this should be a project-level decision, and not cloud-image > specific. I personally am against changing the default. That's > because if someone is installing Debian on student laptops / desktops > at an educational institution like MIT, most of those users really > don't need /sbin and /usr/sbin; Debian users include far more than > just system administrators, kernel developers, and devops types. > > I don't feel very strongly about it, though, so if the project as a > whole thinks Debian should be optimized for technical users, it's not > something I'll lose any sleep over. I replace all of the default > dotfiles for myself, anyway. :-) > > - Ted >
Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH
On Mon, May 20, 2019 at 08:17:09PM -0700, Noah Meyerhans wrote: > At this point, I think it'd be worth revisiting, at the project level, > the historical tradition of leaving the sbin directories out of non-root > paths. Setting aside all the single user desktop and laptop systems, > there are enough alternative ways to grant restricted root (file ACLs, > etc), and to run in alternate filesystem namespaces (e.g. containers), > that the functional distinctions that lead to the original directory > split are probably applicable in a minority of situations these days. Sure, and I often use /sbin/mke2fs on create file system images on plain files and then corrupt them using /sbin/debugfs to create regression tests for e2fsck, and I do all of this w/o being root. So I have /sbin and /usr/sbin and /usr/local/sbin in my path. Along with a whole bunch of other customizations in my dot files, of course. But my usage is an edge case, and asking Debian to make changes to global changes to the defaults for people like me was never something I thought was justifiable. Ultimately, if we believe that someday we'll have the year of the Linux Desktop, where the primary applications used by users are things like Firefox, Open Office, Tuxracer, etc., adding /sbin and /usr/sbin might not be doing those users a favor --- and those of us who are more technical are perfectly capable of customizing our dot files. (Heck, I just pull a git repo into ~/dotfiles, and then run "make install" and I get a custom set of my dotfiles for that installation. :-) > This isn't something that I feel strongly about, though. Anybody who > does should retitle this bug appropriately and reassign it to the > 'general' pseudopackage, whereupon it can be discussed on debian-devel. > Otherwise it should get tagged wontfix, unless someone thinks this is an > appropriate change to introduce at the cloud image level (I would not > agree with this). I agree this should be a project-level decision, and not cloud-image specific. I personally am against changing the default. That's because if someone is installing Debian on student laptops / desktops at an educational institution like MIT, most of those users really don't need /sbin and /usr/sbin; Debian users include far more than just system administrators, kernel developers, and devops types. I don't feel very strongly about it, though, so if the project as a whole thinks Debian should be optimized for technical users, it's not something I'll lose any sleep over. I replace all of the default dotfiles for myself, anyway. :-) - Ted
Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH
Control: severity -1 wishlist > This is a historical convention, going back decades, that only the > system administrators needs to run the programs in /sbin and > /usr/sbin. So to avoid users getting confused when they might run > those programs and get "permission denied", historically normal users > won't have /sbin and /usr/sbin in their path. However many system > administrators will have their own custom dot files which do include > those directories in their paths. > > That assumption is perhaps less likely to be true for servers running > in cloud VM', but making things be different for cloud VM's as > compared to standard Debian configurations also has downsides in terms > of causing greater confusion. So my suggestion would be for you to > simply have your own custom dotfiles which can set a PATH different > from the default. At this point, I think it'd be worth revisiting, at the project level, the historical tradition of leaving the sbin directories out of non-root paths. Setting aside all the single user desktop and laptop systems, there are enough alternative ways to grant restricted root (file ACLs, etc), and to run in alternate filesystem namespaces (e.g. containers), that the functional distinctions that lead to the original directory split are probably applicable in a minority of situations these days. This isn't something that I feel strongly about, though. Anybody who does should retitle this bug appropriately and reassign it to the 'general' pseudopackage, whereupon it can be discussed on debian-devel. Otherwise it should get tagged wontfix, unless someone thinks this is an appropriate change to introduce at the cloud image level (I would not agree with this). noah signature.asc Description: PGP signature
Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH
On Mon, May 20, 2019 at 01:02:25PM -0400, Noah Meyerhans wrote: > On Mon, May 20, 2019 at 11:26:00AM +0200, Jorge Barata González wrote: > >Vagrant image debian/stretch64 v9.6.0 > >/usr/sbin is not included by default in $PATH > > > >``` > >vagrant@stretch:~$ service > >-bash: service: command not found > >vagrant@stretch:~$ /usr/sbin/service > >Usage: service < option > | --status-all | [ service_name [ command | > >--full-restart ] ] > >vagrant@stretch:~$ echo $PATH > >/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > >``` > > That path is set from /etc/profile, which is not modified by the vagrant > images from the default that Debian installs. /usr/sbin is not in the > default PATH in Debian normally. Specifically, /usr/sbin and /sbin are not in the path for non-root users, but they are included for root users: if [ "`id -u`" -eq 0 ]; then PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" else PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" fi (And since you really don't want to be running /usr/games/nethack as root, /usr/games and /usr/local games is not in root's path. :-) This is a historical convention, going back decades, that only the system administrators needs to run the programs in /sbin and /usr/sbin. So to avoid users getting confused when they might run those programs and get "permission denied", historically normal users won't have /sbin and /usr/sbin in their path. However many system administrators will have their own custom dot files which do include those directories in their paths. That assumption is perhaps less likely to be true for servers running in cloud VM', but making things be different for cloud VM's as compared to standard Debian configurations also has downsides in terms of causing greater confusion. So my suggestion would be for you to simply have your own custom dotfiles which can set a PATH different from the default. - Ted
Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH
On Mon, May 20, 2019 at 11:26:00AM +0200, Jorge Barata González wrote: >Vagrant image debian/stretch64 v9.6.0 >/usr/sbin is not included by default in $PATH > >``` >vagrant@stretch:~$ service >-bash: service: command not found >vagrant@stretch:~$ /usr/sbin/service >Usage: service < option > | --status-all | [ service_name [ command | >--full-restart ] ] >vagrant@stretch:~$ echo $PATH >/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games >``` That path is set from /etc/profile, which is not modified by the vagrant images from the default that Debian installs. /usr/sbin is not in the default PATH in Debian normally. If you want to discuss changing this project-wide, we could certainly do so, but that would be quite a bit broader in scope than cloud.debian.org. noah
Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH
Package: cloud.debian.org Severity: normal Vagrant image debian/stretch64 v9.6.0 /usr/sbin is not included by default in $PATH ``` vagrant@stretch:~$ service -bash: service: command not found vagrant@stretch:~$ /usr/sbin/service Usage: service < option > | --status-all | [ service_name [ command | --full-restart ] ] vagrant@stretch:~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games ``` -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
