Read-only mode?

Stef Walter stefw at redhat.com
Tue Nov 3 15:04:13 UTC 2015


On 03.11.2015 15:33, Duncan.Innes at rbs.com 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.fedorahosted.org/pipermail/cockpit-devel/attachments/20151103/804b8501/attachment.sig>


More information about the cockpit-devel mailing list