Bug 143536 - tftp-server rejects valid /etc/tftpd/rules format
tftp-server rejects valid /etc/tftpd/rules format
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: tftp (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
RHEL3U7NAK
:
Depends On:
Blocks: RHEL3U8CanFix
  Show dependency treegraph
 
Reported: 2004-12-21 18:22 EST by Clark Williams
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2006-0312
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-20 10:37:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Clark Williams 2004-12-21 18:22:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
TFTP server rejects the following rule:

r       ^[^/]           /tftpboot/\0    # Convert non-absolute files

with the syslog message:

Dec 21 10:50:14 barn in.tftpd[8294]: r rules cannot be inverted, line
1: ^[^/]           /tftpboot/\0    # Convert non-absolute files



Version-Release number of selected component (if applicable):
tftp-server-0.39-0.EL3.1

How reproducible:
Always

Steps to Reproduce:
1. insure that /etc/tftpd/rules exists and contains the above rule
2. modify the /etc/xinetd.d/tftp file contains:
service tftp
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /tftpboot -m /etc/tftpd/rules -v
        disable                 = no
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}
3. restart the xinetd service
4. put a file in /tftpboot on the server (e.g. /tftpboot/foo)
5. from another system, attempt to tftp the file from the server:
   $ tftp testserver
   tftp> get foo



Actual Results:  TFTP operation failed, syslog contained message from
in.tftpd that 'r rules cannot be inverted

Expected Results:  The file should have been transferred.

Additional info:

Yes, I realize the rule that's listed is a nop when you chroot to
/tftpboot, but the point is that a valid rule (one that is listed in
the source sample.rules file and worked in the previous version)
causes tftpd to fail in mysterious ways. 

Since the listed negation character is a '~' and there is no '~' in
the failing rules file and since there is only one spot in the source
where syslog talks about 'r rules cannot be inverted', I would suspect
some sort of initialization bug?
Comment 1 Bill Barnes 2004-12-22 08:27:43 EST
I'm getting the same error message with this rule too:
rg \\ /
Comment 3 Radek Vokal 2004-12-22 08:59:41 EST
This is already fixed in FC3 tftp-server-0.40. I've backported the
patch into tftp-server-0.39-0.EL3.2 for RHEL3. 
Comment 4 foobarra 2004-12-28 18:20:36 EST
And 0.39-0.EL3.2 will be released when, or is currently available
where?  RedHat introduced an flaw, which should be corrected
quickly...  QA?

And the QA between 2004-10-19 and 2004-12-21 of the U4 released
0.39-0.EL3.1 package, as mentioned in #131736 was where?

Sincerely,
Concerned, upset admin for a supposed Enterprise-Level OS, with
consistantly broken services, from supposedly QA'ed software updates
over the last year.
Comment 7 Michael Shuler 2005-05-20 14:31:08 EDT
Hello,

U5 was released on 5/18, and a mass of subsequent package updates on 5/19, and
tftp/tftp-server was not included, as I was hoping.

Could there, please, be an update posted on the progress of this bug, as well as
the possibility of pushing this as errata, and not waiting another 3-4 months
for a fix?

Kind Regards,
Michael Shuler
Comment 10 Joshua Weage 2005-07-26 08:41:22 EDT
What is going on with this bug?

This one is a serious problem that breaks network installation servers.
Comment 12 Michael Shuler 2005-09-12 18:10:16 EDT
Radek, could this, please, be updated with a target package release date?

Kind Regards,
Michael Shuler
Comment 13 Radek Vokal 2005-09-13 02:48:55 EDT
The fixed package is proposed for RHEL3-U7
Comment 16 Matthew Miller 2005-11-01 18:59:24 EST
Also worth noting re comment #3 that there is no tftp-server-0.40 package in FC3
nor in FC3 updates.
Comment 17 Joshua Daniel Franklin 2005-12-19 16:39:55 EST
This also effects RHEL4. This bug was fixed in tftp-server in September 2004!

http://syslinux.zytor.com/archives/2004-September/004036.html

The FC4 tftp-server-0.40-6.i386.rpm binary works fine on RHEL4.
Comment 18 Michael Shuler 2006-01-27 18:04:25 EST
Hello Radek,

It appears that from the U7 beta package listing that an update will not be
released this quarter.  Could you please confirm, as well as post when this will
be resolved?

Thanks,
Michael
Comment 23 Bob Johnson 2006-04-11 12:22:41 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 3.8 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 3.8 release.
Comment 24 Joshua Daniel Franklin 2006-04-11 13:08:18 EDT
How about RHEL4? It's still at 0.39.
Comment 27 Red Hat Bugzilla 2006-07-20 10:37:30 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0312.html
Comment 29 Issue Tracker 2007-07-06 13:57:35 EDT
Internal Status set to 'Resolved'
Status set to: Closed by Tech
Resolution set to: 'Auto Closed'

This event sent from IssueTracker by pdemauro 
 issue 73224

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