Hi Summary says it all really. To review why dump/restore were originally suid-root, it was to allow non-root users to do network backups. This required a privileged low port etc. Recent versions of dump/restore (including the version shipped with BETA1) support an alternative mechanism which does _not_ require the binaries to be suid-root (or sgid I guess). The mechanism is via an environment variable: RSH. From the man-page of dump RSH Dump uses the contents of this variable to determine the name of the remote shell command to use when doing remote backups (rsh, ssh etc.). If this variable is not set, rcmd(3) will be used, but only root will be able to do remote backups. Also from the man-page Dump cannot do remote backups without being run as root, due to its secu- rity history. Presently, it works if you set it setuid (like it used to be), but this might constitute a security risk. Note that you can set RSH to use a remote shell program instead. So the upstream author explicits recommends no suid/sgid bits and thoughtfully provides an alternative for the few users of non-root network backups. And comments from the field Stelian Pop <pop>: For a default setup, I suggest the second method (you can always enable the suid-root bit later if needed, after reading the man page and accepting the security implications). . Someone else said they were one of the few people who used the network backups as a non-root user, but said they still wished the default was non-suid due to the security implications. Pretty please, consider shipping dump,restore,dump.static and restore.static without any privilege? ;-) At the very least try it for a public beta and see if anyone complains! Chris
Not fixed in BETA2 - version updated Incidentally - am I dreaming or is /sbin/dump missing in BETA2?
fixed today, Chris. thanks.
The setuid bits are gone, but both executables have group tty. I guess they should have group root. Matthew - pedant
Hrm, yes. Fixed in dump-0.4b17-8.