restrict anonymous problem
Andrew Bartlett
abartlet at samba.org
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 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
More information about the samba-technical
mailing list