Bug 56484 - xinetd.d/tftp config invalid, results in errors, non-functioning service.
xinetd.d/tftp config invalid, results in errors, non-functioning service.
Product: Red Hat Linux
Classification: Retired
Component: tftp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-11-19 14:33 EST by Daniel Senie
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-19 14:33:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Senie 2001-11-19 14:33:16 EST
Description of Problem:

The /etc/xinetd.d/tftp file tries to use two conflicting protections. The 
first is to run as 'nobody' while the second is to use the -s parameter to 
chroot() to the specified directory.

It appears, however, that the user 'nobody' is not permitted to chroot() 
and so the tftp fails, logging:

   tftpd[7942]: chroot: Operation not permitted

repeated many times, then:

   xinetd[474]: tftp service was deactivated because of looping

into syslog, and giving the client tftp program no feedback whatsoever 
(looks like a non-responsive host).

Version-Release number of selected component (if applicable):


How Reproducible:


Steps to Reproduce:
1. put a file in the tftp directory specified in the args line of 
the /etc/xinetd.d/tftp file.
2. tftp localhost
3. get <filename from step one, without path>

Actual Results:

hangs, spews errors.

Expected Results:

Additional Information:

changing the 'user = nobody' to 'user = root' solves the problem, and 
makes the config match the pre-xinetd config in inetd.conf in older 
versions of RedHat.
Comment 1 Elliot Lee 2001-12-18 17:28:00 EST
The user=root thing appears to exist in RHL 7.2
Comment 2 Daniel Senie 2001-12-18 18:13:29 EST
Please consider putting out errata for this type of thing, rather than telling 
people to upgrade to the current release. Many folks are using 7.0 and can't 
upgrade due to hardware issues. The errata can just be text indicating how 
people can fix this manually, as opposed to putting out a fixed RPM.

This is what it's all about supporting customers on the releases they use in 
production, vs. playing microsoft and telling people to just upgrade to the 
latest release.

That's my rant on marking bugs fixed as "CURRENTRELEASE". Now back to your 
regularly scheduled programming...

Note You need to log in before you can comment on or make changes to this bug.