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 > >
