On Pá, 2016-10-07 at 11:58 -0500, Michael Catanzaro wrote:
On Fri, 2016-10-07 at 18:07 +0200, Hans de Goede wrote:
>
> Suggested fix if you "shell out to passwd" in g-c-c, then why not
> also do this in g-i-s presumable you can share the code then and
> have less security sensitive code to worry about ? When you do
> make sure you run passwd as root (from g-i-s), not as the newly
> created user. I can set whatever passwd I want using
> "passwd <username>" as root just fine.
We should probably just switch to using accountsservice, which runs
as
root, to change the password; it's kind of silly to use passwd
directly
"for auditability" if it's possible to change passwords using
accountsservice instead. accountsservice should be changed to use
passwd if desired. (Currently accountsservice uses usermod, which is
I
guess why we don't use it in g-c-c.) Does that sound OK, Ondrej?
Then that would solve the problem of getting errors from PAM, and we
can decide whether to enforce password strength in GNOME based on
whether the current user is an admin or not (or if he is
authenticated
as an admin for editing other accounts... that would be kind of
confusing, though, if a non-admin user with access to an admin
password
gets hit by the password strength policy just because he didn't
unlock
the panel with the admin password before changing his password; not
sure what the UI should be for this).
If accountsservice uses usermod it generates audit events too although
slightly different ones than passwd. But that should not be a problem
for auditability.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)