User option (-u or --user) is ignored

[Rodney Beede]

Tested in Ubuntu 12.04 and 13.04.

The --user, -u, or /etc/default/tftpd-hpa TFTP_USERNAME="tftp" options are ignored when running the tftpd-hpa service.

I pulled the source with wget https://www.kernel.org/pub/software/network/tftp/tftp-hpa/tftp-hpa-5.2.tar.xz and compiled.

Ran with

/root/tftp-hpa-5.2/tftpd/tftpd --listen -u nobody --address 0.0.0.0:69 --secure /var

Result was

root@ubuntu:/var/log# ps -ef | grep tftpd
root 7955 1 0 13:55 ? 00:00:00 /root/tftp-hpa-5.2/tftpd/tftpd --listen -u nobody --address 0.0.0.0:69 --secure /var

I expected the process uid to be that of "nobody". Killing the process and trying again I also looked at /proc to see what it thought about it:

root@ubuntu:/var/log# cat /proc/8037/task/8037/status
Name: tftpd
State: S (sleeping)
Tgid: 8037
Pid: 8037
PPid: 1
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 64
Groups: 0
VmPeak: 13048 kB
VmSize: 13048 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 140 kB
VmRSS: 140 kB
VmData: 444 kB
VmStk: 136 kB
VmExe: 32 kB
VmLib: 2140 kB
VmPTE: 44 kB
VmSwap: 0 kB
Threads: 1
SigQ: 0/31432
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000010000
SigCgt: 0000000000004003
CapInh: 0000000000000000
CapPrm: 0000001fffffffff
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
Seccomp: 0
Cpus_allowed: ffffffff,ffffffff
Cpus_allowed_list: 0-63
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 1
nonvoluntary_ctxt_switches: 0

[Seth Arnold (seth-arnold)]

Have you been able to reproduce this problem using the Ubuntu-provided tftpd-hpa package?

[Rodney Beede (business2008+launchpad)]

Yes, that was the first one I tried. I thought the Ubuntu package may have been compiled without the option support so I tried a recompile to ensure it was enabled.

[Marc Deslauriers (mdeslaur)]

The parent process never drops privileges, only the child process which is handling a connection drops privileges. You need to look at the privileges of the child during a connection.

I am closing this bug. If you can demonstrate that the child process isn't dropping privileges, please feel free to reopen it.

Thanks!