[Samba] Confusing behavior of hosts allow/hosts deny in Samba 3.0.28/3.2.4

Mike Gallamore mike at mpi-cbg.de
Thu Nov 6 09:01:45 GMT 2008


I think something like a sudoers file would make since, ie no one gets  
access unless they are on the list. Suggestion:

Perhaps host allow should be the only option. If access controls are  
enabled, people only get access if the host allow field is defined and  
if their name is on the list.
On Nov 6, 2008, at 7:58 AM, Jeremy Allison wrote:

> On Tue, Nov 04, 2008 at 10:43:35AM -0500, Eric Boehm wrote:
>> I saw some unexpected behavior in the interaction of hosts allow and
>> hosts deny on Samba 3.0.28. I built Samba 3.2.4 just to be sure it
>> wasn't something that had been fixed. I saw the same behavior.
>>
>> I'm not sure if it is a bug or a failure on my part to
>> understand the documentation or misleading documentation.
>>
>> If I have a share defined as
>>
>> [export]
>>        comment         = exported storage
>>        path            = /export
>>        # admin users   = boehm
>>        hosts allow     = boehm-1
>>        hosts deny      = boehm-3
>>        oplocks         = no
>>        level2 oplocks  = no
>>        guest ok        = no
>>        create mask     = 0775
>>        directory mask  = 0775
>>        map archive     = no
>>        writeable       = yes
>>
>> Then host boehm-1 has access and boehm-3 is denied access. The odd
>> part is that every other host now has access as well (e.g., boehm-2)
>>
>> Now, if I had only hosts allow and no hosts deny, only host boehm-1
>> would have access.
>>
>>         hosts allow    = boehm-1
>>         # hosts deny   = boehm-3
>>
>> The confusing part, to me, was that adding hosts deny for a single
>> host suddenly opened up the share to every host that wasn't in
>> hosts deny, regardless as to whether they were in hosts allow.
>>
>> The man page for smb.conf has an example for both hosts allows and
>> hosts deny
>>
>>         Example 4: allow only hosts in NIS netgroup "foonet",
>>         but deny access from one particular host
>>
>>         hosts allow = @foonet
>>
>>         hosts deny = pirate
>>
>>         Note Note that access still requires suitable user-level
>>         passwords.
>>
>>         See testparm(1) for a way of testing your host access to
>>         see if it does what you expect.
>>
>> This doesn't mention that every host but pirate will have access, not
>> just those in @foonet.
>>
>> I see this as a bug but I wonder if I am missing something.
>
> I agree it's counter intuitive, but it does match the man
> pages for hosts.allow and hosts.deny, which the original
> code was based on.
>
>> From those man pages :
>
> -----------------------------------------------------------
> ACCESS CONTROL FILES
>       The access control software consults two files. The search  
> stops at the first match:
>
>       ·      Access  will  be  granted  when  a  (daemon,client)   
> pair  matches  an  entry  in  the
>              /etc/hosts.allow file.
>
>       ·      Otherwise, access will be denied when a (daemon,client)  
> pair matches an entry  in  the
>              /etc/hosts.deny file.
>
>       ·      Otherwise, access will be granted.
>
>       A  non-existing access control file is treated as if it were  
> an empty file. Thus, access con‐
>       trol can be turned off by providing no access control files.
> -----------------------------------------------------------
>
> So having a "hosts allow" but no "hosts deny" means the "hosts deny"
> is treated as an empty file (default deny I think). Once you define
> a "hosts deny" then the default changes to "allow", if you only want
> to restrict access to a specific hosts list then don't define a
> "hosts deny", just a "hosts allow". I guess the issue is you
> really don't need to have both defined (maybe we should log
> a warning in this case that the results may not be what you
> would expect).
>
> Jeremy.
>
>
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/listinfo/samba



More information about the samba mailing list