'rsyncd.conf "hosts allow" and ipv6 address matching - possible bug'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rsync
Subject:    rsyncd.conf "hosts allow" and ipv6 address matching - possible bug
From:       "Brian C. Hill via rsync" <rsync () lists ! samba ! org>
Date:       2023-10-12 21:06:04
Message-ID: 9bec5144-1bd0-6495-2df7-37366f9bf0c0 () bch ! net
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

Hello,

If I disable reverse lookups and keep forward lookups enabled, access 
works as expected for fqdn entries in "hosts allow" that have only A 
records (ipv4) records but not for AAAA records (ipv6) when those hosts 
connect via ipv6. I get this error:

    @ERROR: access denied to opt from UNDETERMINED
    (2606:2800:220:1:248:1893:25c8:1946)

    # *cat /etc/rsyncd.conf*
    reverse lookup = false
    forward lookup = true
    read only = true
    list = false
    hosts allow = a.example.com, b.example.com

    [opt]
             path = /opt
             comment = whole opt tree

    # *host a.example.com*
    a.example.com has address 93.184.216.34

    # *host b.example.com*
    b.example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946

    (note that the above hosts/IPs are fictitious and/or loosely used)

rsync from a.example.com succeeds; rsync from b.example.com does not.

PTR records that are unset, set or don't match don't seem to have any 
effect (and they shouldn't).

This is for rsync 3.1.3 on Rocky 8 (rsync-3.1.3-19.el8_7.1.x86_64). This 
seems like either a bug or incomplete implementation of ipv6, I searched 
but could not find any reports of this issue; that leads me to believe 
that this isn't something that is working in the current version, either.

Am I missing something?

Brian
[Attachment #5 (text/html)]

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hello,<br>
    <br>
    If I disable reverse lookups and keep forward lookups enabled,
    access works as expected for fqdn entries in "hosts allow" that have
    only A records (ipv4) records but not for AAAA records (ipv6) when
    those hosts connect via ipv6. I get this error:<br>
    <font face="Courier"><br>
    </font>
    <blockquote><font face="Courier">@ERROR: access denied to opt from
        UNDETERMINED (2606:2800:220:1:248:1893:25c8:1946)</font><br>
    </blockquote>
    <font face="Courier"><br>
    </font>
    <blockquote><font face="Courier"># <b>cat /etc/rsyncd.conf</b><br>
        reverse lookup = false<br>
        forward lookup = true<br>
        read only = true<br>
        list = false<br>
        hosts allow = a.example.com, b.example.com<br>
        <br>
        [opt]<br>
                path = /opt<br>
                comment = whole opt tree<br>
        <br>
        # <b>host a.example.com</b><br>
        a.example.com has address 93.184.216.34<br>
        <br>
        # <b>host b.example.com</b><br>
        b.example.com has IPv6 address
        2606:2800:220:1:248:1893:25c8:1946<br>
        <br>
        (note that the above hosts/IPs are fictitious and/or loosely
        used)<br>
        <br>
      </font></blockquote>
    rsync from a.example.com succeeds; rsync from b.example.com does
    not.<br>
    <br>
    PTR records that are unset, set or don't match don't seem to have
    any effect (and they shouldn't).<br>
    <br>
    This is for rsync 3.1.3 on Rocky 8 (rsync-3.1.3-19.el8_7.1.x86_64). 
    This seems like either a bug or incomplete implementation of ipv6, I
    searched but could not find any reports of this issue; that leads me
    to believe that this isn't something that is working in the current
    version, either.<br>
    <br>
    Am I missing something?<br>
    <br>
    Brian<br>
  </body>
</html>

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[prev in list] [next in list] [prev in thread] [next in thread] 