Re: how auth "local" works and is documented

With the local auth, the hostname is not use.
amanda do a validation to be sure the hostname written in the disklist 
is the same server.
We don't want amanda to backup localhost when the user is expecting to 
backup a remote host.

On 12/04/17 01:50 PM, Chapman Flack wrote:
> Hi,
>
> At $work I inherited an amanda setup where a bunch of the DLEs to be
> backed up are already replicated by other means to the backup server
> (call it 'foo'), so Amanda is making local connections to back them
> up, but the configuration has them using auth "bsdtcp".
>
> I started wondering why they weren't using auth "local", so I changed
> it, and then they didn't work. :) The message was "foo: is not local".
>
> The only thing amanda-auth(7) says about how this works is
>
>    The authenticated peer hostname for this authentication
>    is always "localhost".
>
> but that is specifying what a successful connection returns as
> the peer's hostname. It also seems to be outdated: looks like
> it was changed in 576eff to return something based on gethostname,
> and the current code returns the output of gethostname if that
> succeeds, and "localhost" if it doesn't.
>
> https://github.com/zmanda/amanda/blame/ef53e6f/common-src/local-security.c#L283
>
> But amanda-auth(7) doesn't say anything about what you need to
> write as the host name in the DLE to make the connection succeed.
>
> The answer seems to be (unchanged since the birth of local-security.c)
> that the DLE hostname must be "localhost" or "localhost.localdomain"
> or exactly match whatever gethostname returns.
>
> https://github.com/zmanda/amanda/blame/d78f4b1/common-src/local-security.c#L128
>
> In the case of the setup I inherited, the problem is that the DLE
> uses the short name foo but gethostname returns the FQDN
> foo.example.com. Therefore "foo: is not local".
>
> Probably amanda-auth(7) should describe what's required here.
> But rather than just documenting the current behavior, I'd like
> to suggest:
>
> Instead of having this hardcoded test based on exact spelling
> of names (the "LBYL" style of coding), I would propose that it
> test the ability to bind a socket to an address of the named host
> (the "EAFP" style). Often, especially with security-related functions,
> EAFP style is less error-prone, simply because the OS is aware of
> relevant information that isn't checked by the LBYL code. (The classic
> example of that is where LBYL code carefully checks file owners and
> u,g,o permissions, but the file system has ACLs, or is mounted
> readonly, etc.) So, in pseudocode:
>
>    resolve_hostname(hostname)
>    for each addrinfo ai in result
>      s = socket(SU_GET_FAMILY(ai)...)
>      SU_SET_PORT(ai..., 0)
>      bind(s, ai...)
>      success? close socket, succeed, hostname is local
>      EADDRNOTAVAIL? close socket, continue with next ai
>      Esomethingelse? something else has gone wrong
>    loop finished without success? fail, hostname is not local
>
> That algorithm should succeed with any usable spelling of any valid
> name for the current host, taking into account the possibility of
> multiple interfaces and addresses assigned, and so on.

The algorithm looks good.
Are you going to write a patch?

Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone.  Instead, destroy it and notify me by reply e-mail