Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty password file authenticates all clients #1545

Closed
timothy-godfrey opened this issue Dec 19, 2019 · 3 comments
Closed

Empty password file authenticates all clients #1545

timothy-godfrey opened this issue Dec 19, 2019 · 3 comments

Comments

@timothy-godfrey
Copy link

@timothy-godfrey timothy-godfrey commented Dec 19, 2019

Hello!

I have found that if I specify an empty password file in my configuration file, all username-password pairs connect successfully to the broker.

I'm using the fixes branch of mosquitto, tagged v1.6.8

mosquitto.conf:

per_listener_settings true  

listener 9006
protocol mqtt
require_certificate false
password_file /etc/mosquitto/conf.d/password.txt
allow_anonymous false

password.txt exists, but is empty.

I can send and received messages with the mosquitto_sub and mosquitto_pub clients using any username password combination (including empty strings, but not anonymous clients), whereas I expected that every connection would be refused as unauthorised, based on the mosquitto.conf manpage

If allow_anonymous is set to false, only users defined in this file will be able to connect.

I haven't been able to find any mention in the docs or discussions that this behaviour is by design. I've also had a look for similar issues it the github repo, but didn't find anything. Apologies ahead of time if I've missed something or this is a duplicate.

Thanks!

ralight added a commit that referenced this issue Dec 20, 2019
Previously, authentication checks would only take place if usernames
were defined in the password file.

Closes #1545. Thanks to Timothy Godfrey.
@ralight

This comment has been minimized.

Copy link
Contributor

@ralight ralight commented Dec 20, 2019

This has always been implemented as "only carry out authentication checks if usernames are defined", but thinking about that is counter intuitive. I've just pushed a fix for that.

@ralight

This comment has been minimized.

Copy link
Contributor

@ralight ralight commented Dec 20, 2019

And I forgot to say - thanks for reporting this.

@timothy-godfrey

This comment has been minimized.

Copy link
Author

@timothy-godfrey timothy-godfrey commented Dec 20, 2019

Thanks for the quick update!

Quick tests show expected behaviour.

@lock lock bot locked as resolved and limited conversation to collaborators Mar 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.