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.)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
