ACL Ambigious about volantmq

[troian]

1. Auth subsystem designed to be flexible. The main idea is each listener may have own auth list and it's order. Generally, if two different auth backends can authenticate the same user with different credentials it's a security pothole. Such a case shall not be considered.
   If you have a user with rights to subscribe/publish to any topic (for example using simpleAuth) this user shall have a good password and other auth backends with this listener must not have the user with the same name.
   Regarding storing a reference to the auth backend: I'm not sure it is a good idea though it provides the right use case as you mentioned. I'll give this problem a little think.

2. if e := s.permissions.ACL(s.id, "", pkt.Topic(), vlauth.AccessWrite); e != vlauth.StatusAllow that's a bug. The user should be in there.

[arihantdaga]

Hi @troian I tried to fix it here #169. Let me know your opinion.
Also because of this -

volantmq/cmd/volantmq/auth.go

Lines 38 to 40 in 99c21c3

	func (a *simpleAuth) ACL(clientID, user, topic string, access vlauth.AccessType) error {
	return vlauth.StatusAllow
	}

Simple auth is always allowing by default. I think we'll have to do something if we want to block a user from pub/sub to any topic.
Also this caught my attention -

volantmq/connection/connection.go

Lines 925 to 930 in f15e5d9

	case mqttp.QoS0: // QoS 0
	// [MQTT-4.3.1]
	// [MQTT-4.3.2-4]
	// TODO(troian): ignore if publish permissions not validated
	if err = s.publishToTopic(pkt); err != nil {
	s.log.Error("Couldn't publish message",

This explains why my message passed through even if i set default of simpleAuth to StatusDeny. The message I was publishing was with QOS0
Shall i go ahead trying to fix this ?

[troian]

Yes, that's why it called simpleAuth. It is intended to do user/password authentication not pub/sub. So there is nothing to do with it. pub/sub filtering is up to more complex auth backends

Issue you mention is fixed in pr #168