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 <etienne.moll...@mailoo.org> 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
