On 03.11.2015 15:33, [email protected] wrote: > Is there a read-only mode with the Cockpit interface to allow system > details to be gathered, but not altered?
Cockpit already does this. If you log in with a user that has no access to change anything on the system (ie: a 'nobody' equivalent) then Cockpit. Cockpit itself only has the access privileges of the logged in user. In fact even the cockpit-ws service does not typically run as root. Cockpit runs all operations through a process called cockpit-bridge, started on demand. This cockpit-bridge process is instantiated in a real linux user session ... with the same permissions as if the user had logged in over SSH. Granted this case is not as well tested as the others, so there may be some display bugs in this case. We need to fix those as we find them ... but even in the presence of any such display bugs, when logged in as an unprivileged user, Cockpit will not be able to perform privileged operations. Some more bits here: http://stef.thewalter.net/ideals-of-cockpit.html > Our use for Cockpit would like to see a read-only mode and perhaps a > couple of different read/write mode access levels (middleware team can > only restart httpd & JBoss etc). This should be implemented in terms of policykit. systemd checks with policykit to see if a given user can start/stop a service (or perform any such operation). If you would like to create users/groups that have access to restart httpd and JBoss you would create a rule file and place it in the appropriate place. http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html Once it is in place both systemd and Cockpit and other stuff will respect that. Put another way, without an apprpriate policykit rule in place, an unprivileged user logged into the sistem (whether via Cockpit or SSH) would not be able to perform the privileged task of restarting httpd. The policykit rule file then grants that particular privilege. > I’m looking at this from the > perspective of seeing the Foreman-cockpit plugin this week. This plugin > seems to provide unfettered access for any Foreman user. Is this where > “Deep Integration” will come in? The Foreman plugin currently requires reauthentication. In the demo, the Daniel had already authenticated as an admin with SSO. But yes, when we do deeper integration, it's possible for Foreman to run Cockpit as an unprivileged user (similar to the unprivileged login described above). > Also wondering if it’s possible to write bespoke modules for Cockpit to > allow us to report our specific application stats back via the Cockpit > service. The docs explain how to embed cockpit and use cockpit > components, but not how to integrate our own modules into cockpit (to my > non-developer eyes). Here's some documentation on that: http://stef.thewalter.net/creating-plugins-for-the-cockpit-user-interface.html http://stef.thewalter.net/using-dbus-from-javascript-in-cockpit.html http://stef.thewalter.net/making-rest-calls-from-javascript-in-cockpit.html http://stef.thewalter.net/cockpit-vagrantfile.html Cheers, Stef
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cockpit-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/cockpit-devel
