Re: What are desired semantics for /etc/shells?

[Guillem Jover]

Hi!

On Tue, 2021-06-15 at 13:31:15 +0200, Felix C. Stegerman wrote:
> FYI I just noticed another inconsistency: on my merged /usr systems
> (installed as such, not converted later w/ usrmerge), /etc/shells
> contains both /bin/ and /usr/bin/ paths for some shells, but not all
> (e.g. no /usr/bin/sh, no /bin/screen).
> 
>   $ sort /etc/shells
>   # /etc/shells: valid login shells
>   /bin/bash
>   /bin/dash
>   /bin/rbash
>   /bin/sh
>   /usr/bin/bash
>   /usr/bin/dash
>   /usr/bin/rbash
>   /usr/bin/screen
>   /usr/bin/tmux

Yeah, welcome to the wondrous world of merged-/usr-via-aliased-dirs,
where these paths are aliased, and can be used in places that will
end trying to match against literal entries in /etc/shells, and fail.

While I think I might have been aware of this issue, I never explicitly
tracked it in , added now,
thanks!

Regards,
Guillem

Re: What are desired semantics for /etc/shells?

[Johannes Drexl]

I don't really get the point here:

> Few people would probably *change* /usr/bin/screen to /bin/screen.
Yes, because screen is not a shell. Screen is terminal multiplexer
which just uses a shell. And as such wrappers go, they're not essential
to the OS, but mere a nice to have user command. 

And now taking a look what /bin is all about:

Quoting FHS 3.0:
3.4. /bin : Essential user command binaries (for use by all users)
3.4.1. Purpose
/bin contains commands that may be used by both the system
administrator and by users, but which are required when no other
filesystems are mounted (e.g. in single user mode). It may also contain
commands which are used indirectly by scripts.

(further down there /bin/sh is even listed as a mandatory asset)

And quoting FHS 3.0 further:
4.4. /usr/bin : Most user commands
4.4.1. Purpose
This is the primary directory of executable commands on the system.

Be aware on that topic that FHS 3.0 does not require /usr to be on the
same partition as the root FS, not even being a local FS of sorts nor
being exclusive for the current machine. Shared network storage is a
valid option. On the other hand it is mandatory for /bin and /sbin they
be available when no other FS can be mounted (i. e. no uplink, damaged
/etc/fstab ...), thus they have to be on the root partition, hence the
condition there has to be at least one shell physically available there
for rescuing purposes.

Now one could argue that everything that is not explicitely a mandatory
asset should go to /usr/bin, and I tend to agree to that, but talking
about shells in particular (and not wrappers) I'd say they're quite
essential to a OS, so there's a valid reason for them to be in /bin. 

But then, I'm known to be a little bit of a bean counter considering
those issues, and thus maybe not the best of advisers here. So take my
comment for what you consider it worth. 

BR
Jo


signature.asc
Description: This is a digitally signed message part

Re: What are desired semantics for /etc/shells?

[Felix C. Stegerman]

* Helmut Grohne  [2021-06-28 14:46]:
> On Thu, Jun 24, 2021 at 06:12:05PM +0200, Felix C. Stegerman wrote:
> > It also means that on /usr-merged systems e.g. /bin/screen is not a
> > "valid" shell, but /usr/bin/screen is (even though they are the same
> > file), which may be fine in practice but seems counter-intuitive to
> > me.
> 
> Valid concern. Do you think that I should include machinery specifically
> for handling the /usr merge in update-shells? Automatically adding
> /bin/screen on /usr-merged systems where shells.d contains
> /usr/bin/screen is feasible. I see little value though as
> /usr/bin/screen has always worked on Debian and why would anyone use
> /bin/screen now?

Few people would probably *change* /usr/bin/screen to /bin/screen.

But some people -- maybe new users -- might not know that
/usr/bin/screen is more "traditional"/"canonical" than /bin/screen.

I myself might be tempted to use /bin/screen when editing a file (and
knowing that /bin = /usr/bin on the relevant system(s)) since it's
shorter :)

Also: there's no /usr/bin/sh.  Now *I* would always type /bin/sh, but
setting my shell to $(which sh) would currently result in an invalid
shell:

|$ which sh
|/usr/bin/sh
|$ grep $(which sh) /etc/shells || echo OOPS
|OOPS

Personally, I'd prefer some consistency at least.  Either always
provide both paths on merged /usr systems, or only provide the
"canonical" path on all systems.  Not some shells with both entries
and some with only one.

> #699177

I didn't know about that bug.  Thanks.

- Felix

Re: What are desired semantics for /etc/shells?

[Helmut Grohne]

On Thu, Jun 24, 2021 at 06:12:05PM +0200, Felix C. Stegerman wrote:
> It also means that on /usr-merged systems e.g. /bin/screen is not a
> "valid" shell, but /usr/bin/screen is (even though they are the same
> file), which may be fine in practice but seems counter-intuitive to
> me.

Valid concern. Do you think that I should include machinery specifically
for handling the /usr merge in update-shells? Automatically adding
/bin/screen on /usr-merged systems where shells.d contains
/usr/bin/screen is feasible. I see little value though as
/usr/bin/screen has always worked on Debian and why would anyone use
/bin/screen now?

> >  * While the order of /etc/shells will not be sorted, it will be
> >deterministic if update-shells is run after all packages have been
> >unpacked. Installing two packages one after another will still cause
> >their order in /etc/shells to differ, but changing the order of
> >/etc/shells could break comments left by administrators. So this is a
> >compromise that partially improves reproducibility without regressing
> >maintainability of /etc/shells. I hope that it is sufficient in
> >practice.
> 
> Sorting /etc/shells if the only comment in it is the current
> |# /etc/shells: valid login shells
> on line 1 would seem acceptable to me.

That seems reasonable initially, but it makes the semantics much harder
to understand. You add a special case here.

I think that what I proposed slightly improves reproducibility. It may
not be the final solution, but it also does not make later sorting much
harder. If it turns out that /etc/shells is insufficiently reproducible,
we can fix update-shells and be done as it'll be run in postinst.

For this reasons, I'm in favour of deferring the reproducibility aspect.
I'm not making it any harder and possibly it actually becomes
sufficiently reproducible for practical applications.

> > for f in "$PKG_DIR/"*; do
> 
> Would it make sense to set LC_COLLATE for deterministic ordering here?

That's a good suggestion. I looked into this and things are complicated.
For one thing, whether to set LC_COLLATE depends on where /bin/sh points
to. When it happens to be dash, you run into #699177 and basically don't
care. In any case, setting LC_COLLATE does not hurt. When it happens to
be bash, LC_COLLATE doesn't have to be exported and is honoured
immediately. Therefore, we should set LC_COLLATE prior to globbing even
though the issue is mostly irrelevant (until #699177 is fixed). Thanks.

I also confirm the typo spotted by Étienne Mollier. Thank you as well.

Helmut

Re: What are desired semantics for /etc/shells?

[Bernd Zeimetz]

On Mon, 2021-06-14 at 22:02 +, Holger Levsen wrote:
> On Mon, Jun 14, 2021 at 02:50:29PM -0600, Sam Hartman wrote:
> > As an admin, I expect to be able to install a shell, say because I want
> > to write scripts in it, without allowing users to select it as a login
> > shell.
> > I expect installing a shell, and remove-shelling that shell to work for
> > this purpose.
>  
> 
> 
> 
> point taken, I guess. OTOH, if, as an admin, I apt install a shell, I'd
> assume it to work as a login shell?!? :)

True, but sometimes you have to protect users from doing dumb things.
Or protect yourself from the time you have to spend if users accidentally
choose shells they don't understand.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: What are desired semantics for /etc/shells?

[Étienne Mollier]

Hello,

Helmut Grohne, on 2021-06-24:
> I solicit feedback on this summary and approach. Barring unforseen
> issues, I plan to open a bug against debianutils to incorporate the
> change and once implemented opening bugs against all shell providers at
> normal severity to convert their add-shell/remove-shell calls to
> declarative ones and at rc-severity for not retaining local changes.
> Deferring those bugs post bullseye seems sensible to me as fixing those
> add-shell calls now and later turning them into declarative instructions
> seems like double effort. While the behaviour is not policy-compliant
> now, the number of people running into it must be fairly small.

Thanks Helmut for having taken the time to formalize this.  I do
appreciate Guillem's proposal as well, and I agree with Sam that
your approach is sound.

Is there some place where the present code for update-shell is
hosted?  I think I caught a typo, given the unconditionnal:
> : > "$NEW_STATE_FILE"
I believe that instead of checking for the NEW_STATE_FILE here
below:
> if [ "$NOACT" = 0 ]; then
>   if [ -e "$NEW_STATE_FILE" ]; then
 ^^^
>   chmod --reference="$STATE_FILE" "$NEW_STATE_FILE"
>   chown --reference="$STATE_FILE" "$NEW_STATE_FILE"
you probably meant to check for the existence of the STATE_FILE,
this way:
>   if [ -e "$STATE_FILE" ]; then
 ^^^

In hope this helps,
Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: What are desired semantics for /etc/shells?

[Sam Hartman]

Helmut> I solicit feedback on this summary and approach. Barring
Helmut> unforseen issues, I plan to open a bug against debianutils
Helmut> to incorporate the change and once implemented opening bugs
Helmut> against all shell providers at normal severity to convert
Helmut> their add-shell/remove-shell calls to declarative ones and
Helmut> at rc-severity for not retaining local changes.

Your summary and approach sounds good to me as someone who has tracked
the discussion.


signature.asc
Description: PGP signature

Re: What are desired semantics for /etc/shells?

[Gabor Gombas]

On Thu, Jun 24, 2021 at 06:12:05PM +0200, Felix C. Stegerman wrote:

> * Helmut Grohne  [2021-06-24 08:10]:
> > Felix C. Stegerman cautioned that the contents of /etc/shells depends on
> > whether the underlying system is /usr-merged.
> 
> It also means that on /usr-merged systems e.g. /bin/screen is not a
> "valid" shell, but /usr/bin/screen is (even though they are the same
> file), which may be fine in practice but seems counter-intuitive to
> me.

That will be a problem in environments having a central user database.
Since password entries will be the same on all hosts, the contents of
/etc/shells should also be the same - otherwise, users may not be able to
log in. So /etc/shells changing depending on usrmerge is not just
counter-intuitive, but it has the potential of breaking things.

Gabor

Re: What are desired semantics for /etc/shells?

[Felix C. Stegerman]

Hi,

* Helmut Grohne  [2021-06-24 08:10]:
> Felix C. Stegerman cautioned that the contents of /etc/shells depends on
> whether the underlying system is /usr-merged.

It also means that on /usr-merged systems e.g. /bin/screen is not a
"valid" shell, but /usr/bin/screen is (even though they are the same
file), which may be fine in practice but seems counter-intuitive to
me.

>  * While the order of /etc/shells will not be sorted, it will be
>deterministic if update-shells is run after all packages have been
>unpacked. Installing two packages one after another will still cause
>their order in /etc/shells to differ, but changing the order of
>/etc/shells could break comments left by administrators. So this is a
>compromise that partially improves reproducibility without regressing
>maintainability of /etc/shells. I hope that it is sufficient in
>practice.

Sorting /etc/shells if the only comment in it is the current
|# /etc/shells: valid login shells
on line 1 would seem acceptable to me.

> for f in "$PKG_DIR/"*; do

Would it make sense to set LC_COLLATE for deterministic ordering here?

- Felix

Re: What are desired semantics for /etc/shells?

[Helmut Grohne]

Hi,

I would like to thank you for the many constructive answers. Let me try
to summarize the discussion and try to draw conclusions.

On Thu, Jun 10, 2021 at 08:00:02PM +0200, Helmut Grohne wrote:
> Desired behaviour
> =
> 
> This raises the question of what the desired semantics for `/etc/shells` are.
> Do we want the strict interpretation of the policy to be followed and update
> all those packages to conditionalize their `add-shell` invocations? Or is
> `/etc/shells` a simple collection of installed shells and administrators are
> not supposed to mess with it? The latter interpretation somewhat conflicts 
> with
> our policy, so we might have to update it. If `/etc/shells` is not to be 
> messed
> with, maybe it should not live inside `/etc`?

Consensus seems to be to use the strict policy interpretation: When you
change /etc/shells, upgrades should preserve those changes.

Some related issues were raised:

Richard Laager asked whether it was harmful to list shells that don't
actually exist on the system (such that the file could be shipped
statically). If not, shipping a static /etc/shells would be possible. He
highlighted that this would be bad for third party packages containing
shells. I've not further pursued this option.

Felix C. Stegerman cautioned that the contents of /etc/shells depends on
whether the underlying system is /usr-merged.

Johannes Schauer Marin Rodrigues mentioned (off-list) that /etc/shells
is not reproducible (in terms of reproducible installations) as its
order may differ.

> Declarative packaging
> =
> 
> I think using triggers has an obvious benefit here, but depending in the
> intended semantics of `/etc/shells`, implementing the part about preserving
> user changes may be difficult. A possible solution could be moving
> `/etc/shells` to `/var` and replacing it with a symbolic link when its 
> contents
> match with the generated one one.

There are two proposals for a trigger-based solution:

Mattia Rizzolo extended my proposal of turning /etc/shells into a
symlink with additional files /etc/shells.add and /etc/shells.remove
that would influence the generation of /etc/shells.

Guillem Jover proposed maintaining /etc/shells as a regular file and
updating it using an external state file to recognize additions and
removals by packages.

Both proposals honour the request of allowing administrator changes to
be preserved. My proposal is more heavy handed in the transition code
and bears changes for administrators to adapt to. At present, I favour
Guillem's approach, because it is so unintrusive. It can coexist with
existing maintainer scripts and does not require any flag days.

I've taken Guillem's proposal and turned it into code. I propose adding
a utility update-shells. debianutils would declare a trigger interest in
/usr/share/debianutils/shells.d where other packages can declare their
shells and run `update-shells --root "$DPKG_ROOT"`. I've attached my
implementation of update-shells to this mail. It is written in posix
shell and beyond builtins it only uses dpkg (>= 1.20.1) for
dpkg-realpath and coreutils for chmod, chown, mv, rm, and sync.

How well does this implementation cope with the aspects raised earlier?
 * As per Guillem's proposal it retains administrator addition and
   removal of shells to /etc/shells on update.
 * It does not add shells that do not exist (unless a buggy shell
   includes such a filename).
 * When running update-shells after a /usr-merge, the file will be
   updated with all the relevant realpaths. After dpkg-fsys-usrunmess,
   running update-shells will go back to those that do exist.
 * While the order of /etc/shells will not be sorted, it will be
   deterministic if update-shells is run after all packages have been
   unpacked. Installing two packages one after another will still cause
   their order in /etc/shells to differ, but changing the order of
   /etc/shells could break comments left by administrators. So this is a
   compromise that partially improves reproducibility without regressing
   maintainability of /etc/shells. I hope that it is sufficient in
   practice.
 * The update-shells mechanism will support DPKG_ROOT.

I solicit feedback on this summary and approach. Barring unforseen
issues, I plan to open a bug against debianutils to incorporate the
change and once implemented opening bugs against all shell providers at
normal severity to convert their add-shell/remove-shell calls to
declarative ones and at rc-severity for not retaining local changes.
Deferring those bugs post bullseye seems sensible to me as fixing those
add-shell calls now and later turning them into declarative instructions
seems like double effort. While the behaviour is not policy-compliant
now, the number of people running into it must be fairly small.

Helmut
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright 2021 Helmut Grohne 

# A "hashset" is a shell variable containing a sequence of elements separate

Re: What are desired semantics for /etc/shells?

[Felix C. Stegerman]

Hi!

* Helmut Grohne  [2021-06-10 20:00]:
> […]
> Inconsistency
> =
> 
> Some maintainer scripts take care to only run `add-shell` for initial
> configuration or for upgrading from an ancient version that didn't call
> `add-shell`. Others call `add-shell` for every invocation of `postinst`.
> […]

FYI I just noticed another inconsistency: on my merged /usr systems
(installed as such, not converted later w/ usrmerge), /etc/shells
contains both /bin/ and /usr/bin/ paths for some shells, but not all
(e.g. no /usr/bin/sh, no /bin/screen).

  $ sort /etc/shells
  # /etc/shells: valid login shells
  /bin/bash
  /bin/dash
  /bin/rbash
  /bin/sh
  /usr/bin/bash
  /usr/bin/dash
  /usr/bin/rbash
  /usr/bin/screen
  /usr/bin/tmux

- Felix

Re: What are desired semantics for /etc/shells?

[Guillem Jover]

Hi!

On Thu, 2021-06-10 at 20:00:02 +0200, Helmut Grohne wrote:
> Due to working on installation bootstrap, I was looking into
> `/etc/shells`.
> 
> Introduction
> 
> 
> `/etc/shells` contains valid login shells. Some programs match the configured
> shell of a user against this file to check whether a user is a normal user or 
> a
> system users.

When I was looking into this specific case for
, and looked
for packages accessing that file, I was surprised by the amount of uses
it had. There was also for example a new usage proposed in
 to help remove bash from the essential
set.

> For details on this file refer to `man 5 shells`. On Debian
> systems, it can be managed using the commands `add-shell` and `remove-shell`
> both of which are part of `debianutils`.

BTW I think the BSD man pages are helpful in clarifying its
historically intended use, f.ex:

  

> Inconsistency
> =
> 
> Some maintainer scripts take care to only run `add-shell` for initial
> configuration or for upgrading from an ancient version that didn't call
> `add-shell`. Others call `add-shell` for every invocation of `postinst`.

[…]

> In practice, all of the packages will add their shells on initial
> configuration. The second and third category will also add their shell on
> package upgrades. Arguably, doing so violates Debian policy section 10.7.3,
> which says that package upgrades must preserve local changes (such as removing
> a shell) on upgrades.

> Desired behaviour
> =
> 
> This raises the question of what the desired semantics for `/etc/shells` are.
> Do we want the strict interpretation of the policy to be followed and update
> all those packages to conditionalize their `add-shell` invocations? Or is
> `/etc/shells` a simple collection of installed shells and administrators are
> not supposed to mess with it? The latter interpretation somewhat conflicts 
> with
> our policy, so we might have to update it. If `/etc/shells` is not to be 
> messed
> with, maybe it should not live inside `/etc`?

Given the historic BSD and the current usage and documentation on
non-BSD systems, I'd say it's supposed to be the list of valid login
shells on the system, where valid, to me, implies present and also
sanctioned by the sysadmin. So shell packages should add themselves
once on first install, and remove themselves on remove, and should
thus preserve whether the sysadmin disabled the entry.

This makes it possible for the shell to be installed to satisfy
dependencies, while the sysadmin disallowing its usage as a login
shell, as part of its operational policies or similar, for example.

> Declarative packaging
> =
> 
> Editing `/etc/shells` by running a command during a maintainer script is less
> than ideal when it comes to declarative packaging. The goal of declarative
> packaging is to make reasoning about packages easier by eliminating the need
> for maintainer scripts as much as possible. One solution for this case could 
> be
> `dpkg-trigger`. All the shell-providing packages could drop a snippet into a
> particular directory and `debianutils` could concatenate them into
> `/etc/shells`. Doing so would delete quite a number of maintainer scripts and
> centralize the chance for introducing bugs and inconsistencies such as the 
> ones
> above into one maintainer script.

As mentioned above, for the installation bootstrap stuff, the first
idea that came to mind was adding support for something like
/etc/shells.d/, but after looking for existing users, realized this
was impractical, as the /etc/shells interfaces is rather entrenched
and much code reads from it directly (either hardcoded or via say
_PATH_SHELLS) instead of going through an API like getusershell(3),
so it could not be abstracted within say glibc.

So I agree that generating it from fragments placed elsewhere (say
under /usr), would be better. As I think this should be kept as
sysadmin editable I don't quite like the symlink approach, which in
addition might cause unforeseen issue. But I think preserving the
content should not be difficult, what I think might work is:

 * We'd have:

   - (N) «/etc/shells»,
   - (O) «/var/lib//shells» (or wherever) which is the state,
   - (F) «/usr/share//shells.d/*» (or wherever) which are the
 fragment files the shell packages install.

 * dpkg trigger activates after a package modifies files in (F), runs
   update-shells (or similar), which does:

   1) if (N).new exists, forcibly removes it and (O).new,
   2) if (O).new exists, renames it into (O),
   3) parses (O), or if it does not exist assumed to be the same as (N),
   4) parses (N), preserving comment and blank lines, and for each shell
  line:
  - if it exists on the filesystem, add/keep in (O) and (N),
(this covers the local sysadmin addition and fr

Re: What are desired semantics for /etc/shells?

[Holger Levsen]

On Mon, Jun 14, 2021 at 02:50:29PM -0600, Sam Hartman wrote:
> As an admin, I expect to be able to install a shell, say because I want
> to write scripts in it, without allowing users to select it as a login
> shell.
> I expect installing a shell, and remove-shelling that shell to work for
> this purpose.
 
point taken, I guess. OTOH, if, as an admin, I apt install a shell, I'd
assume it to work as a login shell?!? :)

so, installing a shell should add it to /etc/shells and removing the package
should remove it, but admins changes should be preserved on upgrades?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Re: What are desired semantics for /etc/shells?

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> Hi, Due to working on installation bootstrap, I was looking

Helmut> This raises the question of what the desired semantics for
Helmut> `/etc/shells` are.  Do we want the strict interpretation of
Helmut> the policy to be followed and update all those packages to
Helmut> conditionalize their `add-shell` invocations?

Yes.
A number of people have provided a yes without much reasoning.

As an admin, I expect to be able to install a shell, say because I want
to write scripts in it, without allowing users to select it as a login
shell.
I expect installing a shell, and remove-shelling that shell to work for
this purpose.

--Sam

Re: What are desired semantics for /etc/shells?

[Richard Laager]

On 6/14/21 7:39 AM, Helmut Grohne wrote:

At this time, my personal preference would be turning /etc/shells into a
symbolic link to an autogenerated file.


Is there a harm in /etc/shells containing shells that are not installed 
on the system? If not, then we could ship a single /etc/shells in 
base-files and be done with it. The file would only need to change when 
a new shell is packaged for Debian, which is infrequent; such a change 
would be trivial to make.


One downside would be that third-party repositories, e.g. for a new 
shell, could not add to /etc/shells, in a policy-compliant way. That 
said, Debian Policy is not binding on them anyway.


If it _is_ harmful for /etc/shells to reference shells that do no exist, 
then maintaining the list automatically (by whatever mechanism, 
including the current approach but fixing the bugs) makes sense.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: What are desired semantics for /etc/shells?

[Mattia Rizzolo]

Hello,

I have no personal stake either, the same as the others who already
replied, but I guess I'll chime in as well.

On Mon, Jun 14, 2021 at 02:39:30PM +0200, Helmut Grohne wrote:
> > I think using triggers has an obvious benefit here, but depending in the
> > intended semantics of `/etc/shells`, implementing the part about preserving
> > user changes may be difficult. A possible solution could be moving
> > `/etc/shells` to `/var` and replacing it with a symbolic link when its 
> > contents
> > match with the generated one one.
> 
> At this time, my personal preference would be turning /etc/shells into a
> symbolic link to an autogenerated file. Replacing that link with a
> manually maintained file would keep the original flexibility at the
> slightly increased cost of having to manually update it for added or
> removed shells while providing significant improvements for the vast
> majority of users.

I have an enhancement proposal to your suggestion.

Add an /etc/shells.add and /etc/shell.remove or somesuch, that are
parsed while generating the proposed /var/ file, that are to
be used by the system administrator to instruct the debianutils trigger
to either remove a shell from the list even if it's installed, or to add
a shell to the list even if it's not installed.  It probably means that
the code handling the /var/ file should probably be callable
by other means than just a dpkg trigger, so that the system
administrator can force update the shell list when they update
add/remove files.

This way you'd entirely remove another case where you'd need to remove
the symlink and as such lose the ability to auto-update the file when
you add/remove shells (that are not otherwise already listed in the .add
and .remove files), and, in fact, make it possible for those systems to
be even more declarative since the administrators wouldn't be messing
with files that are already managed by other tools.


(this is somewhat inspired by /etc/hosts.{allow,deny})

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: What are desired semantics for /etc/shells?

[Helmut Grohne]

Hi,

On Thu, Jun 10, 2021 at 08:00:02PM +0200, Helmut Grohne wrote:
> Desired behaviour
> =
> 
> This raises the question of what the desired semantics for `/etc/shells` are.
> Do we want the strict interpretation of the policy to be followed and update
> all those packages to conditionalize their `add-shell` invocations? Or is
> `/etc/shells` a simple collection of installed shells and administrators are
> not supposed to mess with it? The latter interpretation somewhat conflicts 
> with
> our policy, so we might have to update it. If `/etc/shells` is not to be 
> messed
> with, maybe it should not live inside `/etc`?

Since my initial posting, three participants have raise a voice for
applying the strictness of policy to /etc/shells and allowing
administrators to remove shells.

Thus far, none has motivated any practical need, use case or anecdotal
evidence for actually doing so. I also note that anyone doing so would
likely have reported a bug about shells being added back, but that's not
the case. I conclude that the number of users editing their /etc/shells
must be very small.

> I think using triggers has an obvious benefit here, but depending in the
> intended semantics of `/etc/shells`, implementing the part about preserving
> user changes may be difficult. A possible solution could be moving
> `/etc/shells` to `/var` and replacing it with a symbolic link when its 
> contents
> match with the generated one one.

At this time, my personal preference would be turning /etc/shells into a
symbolic link to an autogenerated file. Replacing that link with a
manually maintained file would keep the original flexibility at the
slightly increased cost of having to manually update it for added or
removed shells while providing significant improvements for the vast
majority of users.

Would anyone object to this behaviour?

It would fully eliminate the need to fix up those add-shell/remove-shell
calls.

Helmut

Re: What are desired semantics for /etc/shells?

[Holger Levsen]

On Sun, Jun 13, 2021 at 12:06:43PM +0200, Marco d'Itri wrote:
> On Jun 10, Helmut Grohne  wrote:
> > This raises the question of what the desired semantics for `/etc/shells` 
> > are.
> > Do we want the strict interpretation of the policy to be followed and update
> > all those packages to conditionalize their `add-shell` invocations? Or is
> Yes.

I tend to agree, also because very few packages have those bugs.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Dat gifft in Plattdüütschen keen Woort för „Flüchtlinge”. Dat sünd allens Lüüd, 
Mischen, Kinners, Olle, Froons, Mannslüüd, so as Du un Ick.


signature.asc
Description: PGP signature

Re: What are desired semantics for /etc/shells?

[Marco d'Itri]

On Jun 10, Helmut Grohne  wrote:

> This raises the question of what the desired semantics for `/etc/shells` are.
> Do we want the strict interpretation of the policy to be followed and update
> all those packages to conditionalize their `add-shell` invocations? Or is
Yes.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: What are desired semantics for /etc/shells?

[Étienne Mollier]

Hi Helmut,

Helmut Grohne, on 2021-06-10:
> This raises the question of what the desired semantics for `/etc/shells` are.
> Do we want the strict interpretation of the policy to be followed and update
> all those packages to conditionalize their `add-shell` invocations? Or is
> `/etc/shells` a simple collection of installed shells and administrators are
> not supposed to mess with it? The latter interpretation somewhat conflicts 
> with
> our policy, so we might have to update it. If `/etc/shells` is not to be 
> messed
> with, maybe it should not live inside `/etc`?

With my Debian User and system administrator hat on, I tend to
find the behavior of having shells going back to /etc/shells
after upgrade a bit surprising.  I might find both effects on
chsh(1) and on random services to be of interest, given the
description of shells(5):
>> /etc/shells is a text file which contains the full path‐
>> names of valid login shells.  This file is consulted  by
>> chsh(1) and available to be queried by other programs.
>> 
>> Be aware that there are programs which consult this file
>> to find out if a user is a normal user; for example, FTP
>> daemons  traditionally  disallow  access  to  users with
>> shells not included in this file.

Perhaps I would have liked to reduce the choice of shells for
regular users to a known subset for reasons; I can think of some
distributed applications expecting a specific kind of user
shell, in order to work properly, yet have further command
interpreters for all sorts of needs.  Thus, I'm very tempted to
think bringing back a removed shell to /etc/shells, on a shell
package upgrade, would be a genuine bug against said shell
package.

That being said, this is only my point of view, and I don't
actually meddle much with /etc/shells, so don't really have a
strong opinion on the topic.  Still, I believe that it is
reasonable to think there are installations somewhere which
might rely on administrator maintained /etc/shells, so if it is
due to become solely maintained by software, then it would be
well worth a release note, I guess.

In hope this is of interest for your work on improving packaging
conditions and installation bootstrap,
have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature