Package: firebird2.5-server-common Version: 2.5.2.26540.ds4-12 Severity: normal
There's a fairly complicated set of package relationships here, so bear with me. The root bug that I'm reporting is that I just upgraded libreoffice on a Debian jessie system and ended up with a new "firebird" system user. I found that behavior surprising, since having an office suite installed doesn't seem like it should create new users on my system. (The firebird user also had a valid shell, which creates a variety of other potential issues around security interactions with possible site-local users with the same username. It turns out that the Stanford user with that username has left the university and the account is currently inactive, but....) The user is created through the following dependency chain: libreoffice -> libreoffice-base libreoffice-base -> libreoffice-base-drivers libreoffice-base-drivers recommends libreoffice-sdbc-firebird (I'm not sure why this relationship, but I'm far from an expert on the internals of Libreoffice or the backwards compatibility constraints here.) libreoffice-sdbc-firebird -> libfbembed2.5 libfbembed2.5 -> firebird2.5-server-common I understand that libfbembed2.5 is both a client and a server, and I suspect that it needs some of the other server files. However, does it need the system user? This would moderately surprise me; a userspace library generally can't make meaningful use of system users anyway. I suspect that the system user creation is only required by the actual database server, but libfbembed2.5 needs some other file provided by the same package. I'm not sure the best place to fix this chain of events, but I don't think creating a firebird system user for every person who installs libreoffice without disabling Recommends is the correct course of action. Maybe the individual Firebird server packages can take ownership of the system user? Or the files libfbembed2.5 need can be separated from the rest of the server-common package, particularly the user creation part? I realize that system users tend to get created for somewhat random reasons, and this bug is right on the border between normal and minor. The fact that it had a valid shell and is therefore a minor security risk was the thing that pushed it into a normal bug for me, but the severity is arguable. Regardless of whether this is avoidable behavior, I would at least recommend creating the firebird user with a shell of /usr/sbin/nologin and using the appropriate flags to any invocations of su. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages firebird2.5-server-common depends on: ii adduser 3.113+nmu3 ii firebird2.5-common-doc 2.5.2.26540.ds4-12 ii libc6 2.18-7 ii libfbclient2 2.5.2.26540.ds4-12 ii libgcc1 1:4.9.0-4 ii libicu52 52.1-3 ii libstdc++6 4.9.0-4 firebird2.5-server-common recommends no packages. firebird2.5-server-common suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org