PDA

View Full Version : Need help with tftp problems



ddebevec
14th February 2012, 03:16 PM
First off, I hope Iím in the correct forum. If not, please direct me to the correct one.

Can someone please help me to get my tftp issue straight? What started out as a seemingly simple installation and use of tftp is turning out to be a quite frustrating journey. I based my installation on another userís experience as found on the internet. My first attempts yielded numerous ďpermission deniedĒ messages. After countless searches and trying oh so many suggested configurations, Iím now dealing with the ďcannot set groups for user nobodyĒ messages. Can someone please help lead me out of this tftp nightmare that I seem to be having?

Background

Iím running fedora 14 32 bit and Iíve listed my configurations and messages below:

My latest /etc/xinetd.d/tftp member

service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
server = /usr/sbin/in.tftpd
server_args = -s -c /var/lib/tftpboot -u nobody
per_source = 11
cps = 100 2
flags = IPv4
}

My directory and file permissions and structure:

/var/lib/tfrtboot

drwxrwxrwx 2 nobody nobody 4096 Feb 5 22:39 tftpboot


[root@elisha lib]# cd tftpboot
[root@elisha tftpboot]# ll
total 7724
-rw-rwxrwx 1 root root 165108 Feb 5 22:39 ap61.ram
-rw-rwxrwx 1 root root 165656 Feb 5 22:39 ap61.rom
-rw-rwxrwx 1 root root 3784732 Feb 5 22:39 ar430w-firmware.bin
-rw-rwxrwx 1 root root 3784704 Feb 5 22:39 linux.bin

Output from process status:

[root@elisha /]# ps -ef | grep tftp
nobody 26980 26910 0 21:08 ? 00:00:00 in.tftpd -s /var/lib/tftpboot

Syslog output from execution:

Feb 13 21:08:17 elisha xinetd[26910]: START: tftp pid=26980 from=192.168.20.81
Feb 13 21:08:17 elisha in.tftpd[26981]: cannot set groups for user nobody
Feb 13 21:09:34 elisha in.tftpd[26986]: cannot set groups for user nobody
Feb 13 21:12:16 elisha in.tftpd[26993]: cannot set groups for user nobody
Feb 13 21:13:35 elisha xinetd[26910]: EXIT: tftp status=0 pid=26980 duration=1199(sec)

jpollard
14th February 2012, 03:52 PM
Quite possibly you missed the point that tftpd should run as its own user and not as nobody.

Granted, nobody is better than root. BUT... nobody is given no permissions via SELinux... and I think that should be blocking it from working.

Try the defaults first - it already is supposed to be run as nobody, but the way it gets there may be different than that from the -u option which sets the privileges via /etc/shadow, and you don't want to muck with those as the nobody account gets used for a lot of other things too.

BTW, you also need to check the security labels on the files tftpboot is to provide. I don't think you want them writable at any time either.

flyingfsck
14th February 2012, 03:56 PM
BTW, tftp has NO security. Therefore, it is coded to only allow downloads from a directory that is set to read only.

You probably don't need any of the other things you have done...

bob
14th February 2012, 04:07 PM
moved to EOL (F14's now obsolete)

ddebevec
14th February 2012, 06:11 PM
All,

Thank you for your responses. Iím not currently with my machine, so Iíll have to wait until tonight to try your suggestions. Also I have SELinux disabled, could that be causing my problems?

flyingfsck
14th February 2012, 07:36 PM
SELinux disabled means it does nothing, so don't worry about it. Do read the tftp man page though. Your issues are very like discussed in there.

stevea
14th February 2012, 08:51 PM
BTW, tftp has NO security. Therefore, it is coded to only allow downloads from a directory that is set to read only.

You probably don't need any of the other things you have done...

That's not true. I just tested it.

You will want to kill any currently running daemon and resatart xinetd to effect and /etc/xinetd.d/tftp changes..

sudo pkill -1 in.tftpd
sudo service xinetd restart



service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
server = /usr/sbin/in.tftpd
server_args = -s -c /var/lib/tftpboot -u nobody
per_source = 11
cps = 100 2
flags = IPv4
}

The wait flag should be yes, and that may cause a problem, tho' not likely.

---

I suspect you have a messed up group assignment for nobody account.
grep "nobody:" /etc/{passwd,group}

should return lines like ....

/etc/passwd:nobody:x:99:99:Nobody:/:/sbin/nologin
/etc/group:nobody:x:99:
and maybe others.

If no group entry '99' (based on the /etc/passwd line) with nobody text as an entry - then create it using system-config-users as root.

Then kill the in.tftpd daemon and try again.

ddebevec
15th February 2012, 04:08 AM
I tried your suggestions and now I'm see the message:

Feb 14 18:12:12 elisha xinetd[30244]: START: tftp pid=30248 from=192.168.20.81
Feb 14 18:12:12 elisha in.tftpd[30248]: /var/lib/tftpboot: Permission denied
Feb 14 18:12:12 elisha xinetd[30244]: EXIT: tftp status=66 pid=30248 duration=0(sec)

I removed the "-u nobody" from the "tftp" member, changed the file permissions to read. Changed the owner and group to "nobody" and the wait parameter to yes. I removed all options from the tftp member.

service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = /var/lib/tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}

Is it getting better or worse?

flyingfsck
15th February 2012, 05:49 AM
Howdy,

Do you get more useful error messages if you run it manually?
# /usr/sbin/in.tftpd -s /var/lib/tftpboot

ddebevec
15th February 2012, 06:20 AM
When I execute the command basically the terminal session just goes into a do_wait state and the log displays the following:

Feb 14 20:01:25 elisha xinetd[30914]: START: tftp pid=30931 from=192.168.20.81
Feb 14 20:01:25 elisha in.tftpd[30931]: /var/lib/tftpboot: Permission denied
Feb 14 20:01:25 elisha xinetd[30914]: EXIT: tftp status=66 pid=30931 duration=0(sec)

I'm curious if the file owner, group and permission are correct. I've seen so many different iterations of these values not to mention the user parameter in the tftp member.

jpollard
15th February 2012, 01:40 PM
Server args needs to be "-s /var/lib/tftpboot". This allows the boot process to refer to the files by base name, and not "/var/lib/tftpboot/<basename>".

It also prevents them from downloading password files...

Now as to why it does not have permission, how about reporting the output of the following sequence (sequence and expected results are shown):


$ ls -lZd /var
drwxr-xr-x. root root system_u:object_r:var_t:s0 /var
$ ls -lZd /var/lib
drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 /var/lib
$ ls -lZd /var/lib/tftpboot
drwxr-xr-x. root root system_u:object_r:tftpdir_rw_t:s0 /var/lib/tftpboot
$

forgot one:

$ ls -lZ /var/lib/tftpboot

(mine is empty)

ddebevec
15th February 2012, 02:08 PM
I will post this information this evening, after work. Again, thank you for your assistance in this matter.

flyingfsck
15th February 2012, 05:58 PM
This is the problem: /var/lib/tftpboot: Permission denied

So change the tftp directory to something else and set the owner properly and make both the directory and the file that you want to access, read only.

ddebevec
15th February 2012, 11:39 PM
Here's the output you requested. Looks like mine doesn't match yours. I'm guessing I should try to match yours.


[root@elisha ~]# ls -lZd /var
drwxr-xr-x. root root system_u:object_r:var_t:s0 /var

[root@elisha ~]# ls -lZd /var/lib
drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 /var/lib

[root@elisha ~]# ls -lZd /var/lib/tftpboot
dr--r--r-- nobody nobody ? /var/lib/tftpboot

[root@elisha ~]# ls -lZ /var/lib/tftpboot
-r--r--r-- nobody nobody ? ap61.ram
-r--r--r-- nobody nobody ? ap61.rom
-r--r--r-- nobody nobody ? ar430w-firmware.bin
-r--r--r-- nobody nobody ? linux.bin
[root@elisha ~]#

jpollard
16th February 2012, 01:55 AM
There it is.

I believe the directory /var/lib/tftpboot must have rx.

x allows the directory to be searched, and I believe that is what in.tftpd does when it starts.

The files in the directory are fine.

ddebevec
16th February 2012, 03:59 AM
I hope I didn't miss anything, but I think we're back where we started.

[root@elisha lib]# ls -lZd /var
drwxr-xr-x. root root system_u:object_r:var_t:s0 /var

[root@elisha lib]# ls -lZd /var/lib
drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 /var/lib

[root@elisha lib]# ls -lZd /var/lib/tftpboot
drwxr-xr-x root root ? /var/lib/tftpboot

-Note I also tried this with "nobody" as owner and group. Same results.

[root@elisha lib]# ls -lZ /var/lib/tftpboot
-r--r--r-- root root ? ap61.ram
-r--r--r-- root root ? ap61.rom
-r--r--r-- root root ? ar430w-firmware.bin
-r--r--r-- root root ? linux.bin

-Note I also tried this with "nobody" as owner and group. Same results.

Added -s to the tftp member

service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /var/lib/tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}

Do I need to do a chcon to the tftpboot directory?

Thanks,

David

---------- Post added at 07:59 PM ---------- Previous post was at 07:53 PM ----------

I forgot, the syslog output is:

Feb 15 19:39:58 elisha xinetd[26728]: START: tftp pid=26733 from=192.168.20.81
Feb 15 19:39:58 elisha in.tftpd[26734]: cannot set groups for user nobody
Feb 15 19:42:27 elisha xinetd[26728]: EXIT: tftp status=0 pid=26733 duration=149(sec)

Feb 15 19:43:07 elisha xinetd[26761]: START: tftp pid=26766 from=192.168.20.81
Feb 15 19:43:07 elisha in.tftpd[26767]: cannot set groups for user nobody
Feb 15 19:58:07 elisha xinetd[26761]: EXIT: tftp status=0 pid=26766 duration=900(sec)

jpollard
16th February 2012, 03:27 PM
You need to do a "restorecon /var/lib/tftpboot" only if you plan on using SELinux to protect your system.

Does the /etc/group file have an entry like "nobody:x:99:"?

ddebevec
16th February 2012, 03:55 PM
That was one of the things that was suggested earlier. I ran grep "nobody:" /etc/{passwd,group} a few days ago and I think I received the following output:

/etc/passwd:nobody:x:99:99:Nobody:/:/sbin/nologin
/etc/group:nobody:x:99:

I'll verify it tonight.

I also ran into another post that found success in stopping xinetd altogether and running in.tftpd indpendently. Their though was xinetd did something to in.tftpd that adds restrictions to it. Something else to try.

Again, thanks for everyones assistance,

David

jpollard
16th February 2012, 04:01 PM
For that, you might check the /etc/host.allow and /etc/host.deny lists (man tcpd, man 5 hosts_options

The advantage that xinetd has is the control - you can specify exactly what network to listen for. This is more important when you have multiple network connections.

ddebevec
17th February 2012, 12:07 AM
OK, I'll take a look at those tonight. Just to let everyone know, I'm running a pretty vanilla system. It's just perplexing to me that this issue should be this challenging short of a missing patch. Just for the record, Iíve faithfully applied all recommended patches that where available over the years.

Thanks,

David

---------- Post added at 04:07 PM ---------- Previous post was at 08:24 AM ----------

Like I said, it's a pretty vanilla installation ...

[root@elisha ~]# grep "nobody:" /etc/{passwd,group}

/etc/passwd:nobody:x:99:99:Nobody:/:/sbin/nologin
/etc/passwd:nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
/etc/group:nobody:x:99:
/etc/group:nfsnobody:x:65534:
[root@elisha ~]#

#
# hosts.deny This file contains access rules which are used to
# deny connections to network services that either use
# the tcp_wrappers library or that have been
# started through a tcp_wrappers-enabled xinetd.
#
# The rules in this file can also be set up in
# /etc/hosts.allow with a 'deny' option instead.
#
# See 'man 5 hosts_options' and 'man 5 hosts_access'
# for information on rule syntax.
# See 'man tcpd' for information on tcp_wrappers
#
[root@elisha ~]#

#
# hosts.allow This file contains access rules which are used to
# allow or deny connections to network services that
# either use the tcp_wrappers library or that have been
# started through a tcp_wrappers-enabled xinetd.
#
# See 'man 5 hosts_options' and 'man 5 hosts_access'
# for information on rule syntax.
# See 'man tcpd' for information on tcp_wrappers
#
[root@elisha ~]#

jpollard
17th February 2012, 12:42 AM
I think you want to enter a "tftpd" entry for a network in the hosts.allow (or a specific entry for each host) There is an example in the manpage for hosts_access for in.tftpd.

ddebevec
21st February 2012, 06:28 PM
I would like to update my progress on this issue. I tried various access permissions, but I still received either the ďpermission deniedĒ or the ďcannot set groups for user nobodyĒ message. I hate to say this, but I finally resorted to doing my initial task with a VirtualBox session of Windows XP. I would like to thank everyone that contributed to this effort and Iím intending to upgrade to the current version of Fedora soon.

Thanks Again,

David