Bug#248145: kuser does not use adduser, might do policy violations
Hi Pierre,
I submitted the bug because handling some users with kuser did interfere in
with the regular tools on my system.
I figured it is because kmail does not use the mechanisms provided in debian
to alter conf files.
Fine if kuser will now delete private groups of users when they have one,
simulating the provided tools (adduser/useradd), that did mess up my setup
once. Even though it's probabably only emulating some things.
There is more to it though, and a kuser option to use the standard tools
instead of writing to the files directly (locking etc.) would never risk to
interfere.
The points where only examples.
Am Friday 23 September 2005 09:23 schrieb Pierre HABOUZIT:
> > -- User private group IDs != UIDs
>
> I don't see any problem here. This is a common thing in heavily
> multi-user unices to have different UID/GID, and this doesn't generate
> any bug at all.
from /etc/login.defs
# Enable setting of the umask group bits to be the same as owner bits
# (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
# the same as gid, and username is the same as the primary group name.
#
# This also enables userdel to remove user groups if no members exist.
#
USERGROUPS_ENAB yes
# If defined, this command is run when removing a user.
# It should remove any at/cron/print jobs etc. owned by
# the user to be removed (passed as the first argument).
#
#USERDEL_CMD /usr/sbin/userdel_local
> > -- kmail copies a complete .kde directory into new users home
> > (should be handled by kde itself on firs login)
>
> IMHO, this has nothing to do with the "problem" you report here.
Sorry, this was a typo. It was of course *kuser* that created ~/.kde
directories.
Regards,
Christian
Reply to: