restrict anonymous problem

[Andrew Bartlett]

Andy Bakun wrote:
> 
> On Wed, 2002-06-19 at 09:29, Andrew Bartlett wrote:
> > Read the manpage.  Restrict anonymous doesn't (in 2.2) do what you would
> > expect.  Its a bit weird, and basiclly useless.
> >
> > As to 'guest ok = no', I don't think you can set that for IPC$.
> 
> Depends on your definition of "restrict" (and "weird") -- think
> restricted shell (bash -r), you can still use a shell, but what you can
> do has been limited.  It does limit anonymous access, but it doesn't
> make anonymous access fail in all cases.  It only makes anonymous access
> fail if there is already an authenticated connection from that client.
> This makes username based macro substitutions predictable, as NT clients
> like to browse share listings anonymously even though they already have
> an authenticated connection.  They attempt anonymous browse, which
> fails, then try again using the authenticated connection they already
> have (this process that NT uses seems backward to me, and I can't be the
> only one).  Restrict anonymous was designed to get around this problem.

I would have 'expected' restrict anonymous to behave like the NT
registry setting, and to impose a 'restriction' on the actions of
anonymous users.

> I know this option was discussed before, but what about 'restrict
> anonymous' is different in post 2.2 samba?  I was told it was going to
> be removed (or may have been already in post 2.2 versions).  If
> 'restrict anonymous' is actually going to not allow anonymous
> connections, then how is that different than 'guest ok' or not setting a
> guest account?  

The 'new, improved' restrict anonymous smb.conf parameter now controls
access to *some* IPC calls in the same way NT does.  It still allows
many others, like user password changes etc.

> The whole 'restrict anonymous' thing would be useless if
> include= lines with macros in them were tried for all current values of
> vuser (I think that's the variable) for all connections from that
> client.

I'm not sure that is practical in the current infrastructure, and simply
proves that if you abuse samba's macros too badly that they *will* come
back and bite you.

> This is kind of funny because when 'restrict' was suggested as the name
> for this option, it made perfect sense.  I can not come up with a usage
> of 'restricted access' that means 'no access', restricted means limited,
> but apparently there's a misunderstanding when people see 'restrict
> anonymous'.

Could you try out your problematic include= lines with the current HEAD
branch?  I think that tpot's last batch of changes might have 'merged'
the conflicting interests in this option....

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net