On Thu, Aug 6, 2020 at 5:47 AM Stephen J. Turnbull <stephen@xxxxxxxxxx> wrote:
I'm really uncomfortable about the amount of crossp-posting, so I'm
limiting this to devel@ (I receive it) and test@ (obvious to me why
relevant).
Kamil Paral writes:
> Adam writes:
> > Arguably the environment from which they logged in is not
> > "working as expected" if you can't then log in as someone else.
>
> However, the existing basic criterion [1] only requires the *initially*
> created user to be able to log in. So if you create a second user, and
> can't log in with it after a system boot,
Adam's argument is that this is covered by "working as expected".
It's not covered in the situation I described. Adam's quoted criterion only applies after log out, and so it doesn't apply to secondary users (created after system installation) which try to log in immediately after system boot (so there is no previous log out) and it fails.
FWIW, I think that the criterion should be something like
users created by *scripts* as part of a *supported* installation
or upgrade process and which are documented as able to log in,
must be able to log in from any condition where login is
documented to be possible. Logging out must return the login
facilities to the state in which log in occurred unless some
*condition* (such as shutdown in progress) *explicitly* changes
it.
I don't think we should only guarantee login for users created during installation. That seems very poor QA and I wouldn't want to use a system in which I can create a user but it can't log in and "it's OK". We should guarantee login for all users which pass some sanity check (i.e. you create them using standard tools and approaches and don't do anything horrible to them). Unlike your proposed criterion (which is very convoluted to cover those corner cases), I don't think we need to specify them. That's the point of the blocker meeting, to discuss that particular situation. If somebody removed their login shell, well, that's clearly not our problem and not a criterion violation - it doesn't need to be codified. On the other hand, if a regular system update removed that login shell, that's a big bummer on our side. I prefer easy-to-understand criteria which might not cover all corner cases (they'll never will, even if you try), but convey the intended goal well, and people can then use them as a basis for decision making (while considering all the circumstances).
I'm not sure what you mean by "documented". I wouldn't rely on Fedora documentation too much in these cases. So that would mean we'd also need to create and maintain some lists of "which users are supposed to be able to log in" and "in which conditions the logins are possible".
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
