Package: nfs-user-server Version: 2.2beta47-20 Severity: critical Hello,
until yesterday I had nfs-server installed. This one contained rpc.mountd which according to man rpc.mountd chooses a random port number in case none is preconfigured. This had almost desastrous consequences upon the last bootup of my server: That time it decided to grab port 622, which is my reconfigured SSH port (some security measure, I wouldn't want to have standard port 22 open worldwide). Thus my ssh server (started AFTER the NFS server) detected that port 622 was in use, threw its arms into the air in despair, withered and died. In other words, this random port selection (in the pre-1024 range?) may KILL REMOTE ACCESS TO AN ENTIRE BOX! I was a very lucky bastard who still had telnetd installed for access from the local net to my headless server, so I was able to figure out the problem after some very puzzled minutes. I assume that the rpc.mountd contained in the current nfs-user-server package has the same behaviour, i.e. choosing random ports if no port is preconfigured (the same "random port" notice is mentioned in the man page of this version, and a first netstat -a test seems to confirm it, with ports 633 and 820 chosen). Given the severity of this problem, adding a very visible note to the package description (dpkg -s) or choosing a preconfigured port in the default package configuration (better?) would probably be a very good thing to do. I was unsure which Severity to choose for that (http://www.debian.org/Bugs/Developer#severities), but given that it may kill important services if it gets started on the same port as those before those get started, I rated it as "critical" (which is very high, admittedly, breaking Debian release processing). Feel free to rate it down if you think it is less severe, but it can kill access to the whole box after all (and it does break "unrelated software", as listed in the very definition of the "critical" severity, and even randomly, so it's not even predictable which service will fail on next bootup or runlevel change). Thank you, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
