On Mon, Sep 19, 2016 at 10:23 PM, Martin Bammer <mrb...@gmail.com> wrote:

> Hi,
> I was playing around with extending and fixing some bugs in the
> usermanager. One
> of the bugs I would like to get fixed is setting the avatar for users.
> As I've seen in the code changing the avatar does not check for which user
> the
> avatar was changed. It always changes the avatar of the currently logged in
> user. Fixing this would mean either disable the possibility to change other
> user's avatar in the GUI (the easier solution) or to take care which user's
> avatars were changed and write the temporary files to the correct
> destination.
> As long as the home directories are not encrypted this could be done with
> root
> rights. In case of encrypted homes every user, which avatar was changed,
> would
> have to enter his password after clicking the Apply button. Not a nice
> solution.
> Yeah, we've got an open bug on that.
I've just made a patch for KUser which will allow us to get rid of saving
into ~/.face

> In addition the avatar is not set for the login manager. As I've seen in
> the
> sources SDDM is just ignoring the avatars in the folder
> /var/lib/AccountsService/icons. So adding this search folder as the
> primary
> source would be a good idea. Then it does not matter if the homes are
> encrypted
> or not.

SDDM has a patch pending for using AccountsService
It should be in 0.15

> Some additional features I would like to have:
> - Selecting user's groups, like it is possible in Mint.
> - An option to show the home's encryption key. Currently the user has
> exactly 1
> chance to write down his encryption key. Later he has to google how this
> can be
> done and has to use the command line for this. Not user friendly.
> - An option to easily enable/disable home's encryption. Currently only the
> first
> user who installs the system can enable the encryption for him in the
> installer.
> But for every new user who want to have an encrypted home the command line
> is
> needed.
> - Maybe also an option to choose the user-id and group-id for new users.
> The
> current implementation has IMHO a design problem: The first user gets id
> 1000
> (on Debian based systems, on RedHat based systems 500). The second 1001
> and so
> on. But what if we have a small home network where everyone has it's own
> machine, thus different users have the same id? Problems arise when
> sharing with
> NFS or when using external drives with a Linux FS. My suggestion would be
> to
> calculate hash values out of the user and group names to get the ids. Not
> perfect, but much better than the current implementation. But this is a
> topic
> for the base system and not for the usermanager.
> Here a screenshot how this could look like:
> Your suggestions are very welcome.
> Best regards,
> Martin Bammer

Reply via email to