Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#41982 - [amule] useradd should have "-r" option

Attached to Project: Arch Linux
Opened by Zhuoyun Wei (wzyboy) - Monday, 15 September 2014, 17:14 GMT
Last edited by Antonio Rojas (arojas) - Thursday, 18 February 2016, 20:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Giovanni Scafora (giovanni)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:

post_install() function of amule package adds a user named "amule". As this is a system user, it should be created with "-r" option, so the uid would be chosen from SYS_UID_MIN-SYS_UID_MAX range.


Additional info:
* package version(s): 10834-2


Steps to reproduce:
* Install the package.
* Run "id amule" to see its uid.
This task depends upon

Closed by  Antonio Rojas (arojas)
Thursday, 18 February 2016, 20:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  amule 10874
Comment by Johannes Löthberg (demize) - Monday, 15 September 2014, 17:56 GMT
So, what is the UID it gets and what is it that you expect?
Comment by Zhuoyun Wei (wzyboy) - Tuesday, 16 September 2014, 01:37 GMT
According to /etc/login.defs:

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN 1000
UID_MAX 60000
# System accounts
SYS_UID_MIN 500
SYS_UID_MAX 999


"amule" is a system account, it should has a uid ranges from 500 to 999, rather then a "human" uid which is greater than 1000. My laptop has two human accounts, uid 1000 (me) and uid 1001 (my girlfriend). After I installed amule, the "amule" account occupies uid 1002.

This should be fixed by adding "-r" option to "useradd" command in post_install() function.

Adding "-r" options will also, according to useradd(8), bring the benefits of "with no aging information in /etc/shadow".
Comment by Zhuoyun Wei (wzyboy) - Monday, 20 April 2015, 13:16 GMT
  • Field changed: Percent Complete (100% → 0%)
Why just "won't fix" after 5 months of inactivity? The bug is not fixed at all.

When adding users and groups in post_install(), it is a convention to add system accounts, not human accounts. See redis, transmission, and lightdm for examples:

https://projects.archlinux.org/svntogit/community.git/tree/trunk/redis.install?h=packages/redis

https://projects.archlinux.org/svntogit/packages.git/tree/trunk/transmission-cli.install?h=packages/transmission

https://projects.archlinux.org/svntogit/community.git/tree/trunk/lightdm.install?h=packages/lightdm

They, and many others, if not all, add "SYS" users and groups, not human ones.

So why does amule just want to behave as a human user?
Comment by mauro (lesto) - Thursday, 07 May 2015, 16:58 GMT
+1

temporary fix, as root:

userdel amule
getent group amule >/dev/null || groupadd amule
getent passwd amule >/dev/null || useradd -r -c 'aMule Client' -g amule -d '/var/lib/amule' -m -s /bin/false amule
Comment by Pablo Lezaeta (Jristz) - Saturday, 30 May 2015, 13:43 GMT
I was gonna add another bug about this issue but notice this repport.

Amule even update and the bug persist, I also notice that the package not remove the users that they add add, why?

The maintainer is even aware of this bug? and aware of this: https://www.archlinux.org/todo/usergroup-management/ ?
Comment by Johannes Löthberg (demize) - Sunday, 31 May 2015, 15:52 GMT
While an UID and GID should be allocated for this package, not removing the users is correct.

There is literally no reason to remove users on uninstall, but there is several reasons for keeping them. This package in particular can have user files owned by the amule user left after uninstalling, and then when another package creates a user the UID/GID could be reused
Comment by mauro (lesto) - Sunday, 31 May 2015, 16:26 GMT
not removing the user is standard as also the link posted state:

>These should never be removed automatically as it poses a security risk if any files are left behind with this ownership.
Comment by Pablo Lezaeta (Jristz) - Sunday, 21 June 2015, 21:49 GMT
but you need anyway move the used ID out of the 1000+ when it fixed this
one cant 'spect this to be fixed if you keep having amule as a normal user rather than a "-r".

maybe move the user below the 1000 in the new update too?
also, amule updated, bug and ToDo not done, why?

Loading...