Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1221291

Summary: Add protocol support for MQTT to selinux policies
Product: [Fedora] Fedora Reporter: Peter Robinson <pbrobinson>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dominick.grift, dwalsh, lvrabec, zpytela
Target Milestone: ---Keywords: Tracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1269538    

Description Peter Robinson 2015-05-13 15:45:22 UTC
It would be useful to have a selinux policy for MQTT (MQ Telemetry Transport) to enable to run a MQTT server/broker in enforcing mode.

From the broker side there are currently 3 message brokers that can support MQTT. ActiveMQ, RabbitMQ and mosquitto.

mqtt ports are as follows:
1883/tcp for non encrypted mqtt traffic
8883/tcp for mqtt over SSL/TLS

http://mqtt.org/faq

At least with mosquitto testing it doesn't work in enforcing mode, I couldn't find the port details. Possibly need to file system changes too but I'm not sure what I need to supply there, and presumably it's broker/server specific unlike the port?

Comment 1 Jan Kurik 2015-07-15 14:09:57 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 2 Jan Kurik 2016-02-24 13:24:07 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 3 Fedora Admin XMLRPC Client 2016-09-27 15:04:33 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Peter Robinson 2017-04-23 09:53:58 UTC
Any update?

Comment 5 Lukas Vrabec 2019-07-10 07:32:29 UTC
Hi All, 

Is this still actual? 

Thanks,
Lukas.

Comment 6 Peter Robinson 2019-07-10 12:12:03 UTC
> Is this still actual? 

What do you mean by actual? If you mean if it's still a requirement, yes.

Comment 7 Peter Robinson 2019-11-01 12:41:04 UTC
Why did you remove tracking?

Comment 8 Zdenek Pytela 2019-11-07 07:18:29 UTC
Peter,

This is how Tracking is described in bugzilla:

This bug is a tracking bug. That means that this bug is only used as a placeholder for a particular set of changes which are split over a number of different bugs. All those bugs can be set to block this Tracking bug, so we have an easy way to query the status of a larger project based on the dependency tree of the Tracking bug. Tracking bugs do not require a release flag or acks.

Did you really mean it this way?

Comment 9 Peter Robinson 2019-11-09 11:17:26 UTC
(In reply to Zdenek Pytela from comment #8)
> Peter,
> 
> This is how Tracking is described in bugzilla:
> 
> This bug is a tracking bug. That means that this bug is only used as a
> placeholder for a particular set of changes which are split over a number of
> different bugs. All those bugs can be set to block this Tracking bug, so we
> have an easy way to query the status of a larger project based on the
> dependency tree of the Tracking bug. Tracking bugs do not require a release
> flag or acks.
> 
> Did you really mean it this way?

It also means it's not closed or moved to a specific release when it's not been fixed and it's an RFE so yes, I meant to have it on tracking so it doens't get closed and i don't have to keep moving it until it's implemented.

Comment 10 Fedora Admin XMLRPC Client 2020-01-23 16:23:53 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.