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".
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.
By "scripts" and "supported" I mean to rule out situations where a
admin abused the facilities (such as after generating the standard
users root and alice by answering the "username" and "password"
questions, they go on to create bob and cindy and misspecify the
user's shell). Of course if user error occurs, we should see if we
can do better, but my understanding is that this is a criterion for
"blockers", and that's why I want to rule out user error.
By "explicit condition" I mean that if a bug is reported "I can't log
in after X" and it is determined that some condition holds that
prevents the login, it's OK to either fix the condition, or document
that that condition prevents login. Similarly, documenting is OK if
something happens after logging out that the user didn't expect, but
on reflection seems reasonable from the point of view of the
development community.
Another plausible admin error case is where some user has decided to
make obsoletewhenfirstreleasedsh their shell and the "supported
process" *deletes* that shell. (We might want to fix that one rather
than documenting it, since it's easy enough to check. For all I know,
we already do! I've never deleted a shell package. ;-)
Steve
_______________________________________________
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
