From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-0.1.19 i686) Adding two different users with `useradd' may result in them owning the same cron file. For example, the users aaaaaaaaaabbbbbbbbbbccccccccccdd aaaaaaaaaabbbbbbbbbbccccccccccd will have the same cron file. Reproducible: Always Steps to Reproduce: 1. useradd aaaaaaaaaabbbbbbbbbbccccccccccdd 2. crontab -e -u aaaaaaaaaabbbbbbbbbbccccccccccdd 3. ls /var/spool/cron/aaaaaaaaaabbbbbbbbbbccccccccccd Actual Results: /var/spool/cron/aaaaaaaaaabbbbbbbbbbccccccccccd is created. Only one d at the end. Expected Results: The cron file's basename should be the same as the user's name: /var/spool/cron/aaaaaaaaaabbbbbbbbbbccccccccccdd It is possible to fix the bug by changing MAX_UNAME to 33. Instead, I think it is better to provide a solution that dynamically allocate space for User[] and RealUser[]. Indeed, otherwise a change in useradd (it allows, say, 40 char usernames) will trigger the bug again.
Just cleaning up old bugs here. This really isn't an issue - cron's MAX_UNAME IS now 33; the maximum length of a username for Linux is still 32 (and probably always will be) . If and when that changes, will reassess.