Re: What are desired semantics for /etc/shells?
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
Reply to: