restrict anonymous problem

Andrew Bartlett abartlet at
Thu Jun 20 01:14:04 GMT 2002

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
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at

More information about the samba-technical mailing list