Hi Cockpit developers,
I saw that on cockpit-209 Session timeouts were added with the default to 15 minutes of inactivity (https://cockpit-project.org/blog/cockpit-209.html ). I think that this change is problematic because: 1. The timeout is very short and it can cause unexpected behavior to users and cockpit packages. 2. The timeout can only be configured in the /etc/cockpit.conf file, so it is hard for packages to configure it to fit to their behavior.
For example, we created a package for installing ovirt with cockpit UI, that installation can take a lot of time, it has different phases and logging out in the middle can cause problems. We prefer to avoid editing /etc/cockpit.conf because we don't want to run over user configuration (what to do when there is already cockpit.conf present?)
I want to suggest: 1. Raising the timeout to 2 hours of inactivity, this seems reasonable. 2. Provide a more flexible way of configuring the timeout, with an option to the manifest.json package file and/or with a cockpit API call.
Thanks
Hi Gal,
We took the 15 min timeout from GDM and this is based on Common Criteria. The suggested 2h is just too much. The engine-setup process should not depend on cockpit session being around. It needs to run even when you log out of Cockpit and the user should be able to see the running process output when they log back in again.
Regards, Katerina
On Mon, Mar 30, 2020 at 12:12 PM Gal Zaidman gzaidman@redhat.com wrote:
Hi Cockpit developers,
I saw that on cockpit-209 Session timeouts were added with the default to 15 minutes of inactivity (https://cockpit-project.org/blog/cockpit-209.html). I think that this change is problematic because:
- The timeout is very short and it can cause unexpected behavior to users and cockpit packages.
- The timeout can only be configured in the /etc/cockpit.conf file, so it is hard for packages to configure it to fit to their behavior.
For example, we created a package for installing ovirt with cockpit UI, that installation can take a lot of time, it has different phases and logging out in the middle can cause problems. We prefer to avoid editing /etc/cockpit.conf because we don't want to run over user configuration (what to do when there is already cockpit.conf present?)
I want to suggest:
- Raising the timeout to 2 hours of inactivity, this seems reasonable.
- Provide a more flexible way of configuring the timeout, with an option to the manifest.json package file and/or with a cockpit API call.
Thanks _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste...
On Tue, Mar 31, 2020 at 6:52 PM Katerina Koukiou kkoukiou@redhat.com wrote:
Hi Gal,
We took the 15 min timeout from GDM and this is based on Common Criteria.
I urge you to reconsider.
I am not a security expert, but was a sysadmin for 15 years before joining Red Hat 7 years ago (as a developer).
I think that the gdm case is different. There, you lock the session, not logout. Right? If so, after re-entering the password, the admin has everything back there.
No idea what timeout applies to logging out a session. I do not believe it's 15 minutes. I think I never used a web application that required to login again after 15 minutes.
Also: Does Red Hat now by default configures sshd to logout sessions after 15 minutes? If not, what's the difference?
The suggested 2h is just too much. The engine-setup process should not depend on cockpit session being around. It needs to run even when you log out of Cockpit and the user should be able to see the running process output when they log back in again.
OK, how? Do you have an example for a cockpit module/plugin/whatever that does that? That runs a long-running command, saves its output somewhere, and if being logged out in the middle, allows the user to reconnect, showing everything since the last part already seen by the user? Does cockpit have means to help plugin authors do that, without reinventing the wheel every time?
We want to do that for a long time now:
https://bugzilla.redhat.com/show_bug.cgi?id=1422544
But neglected it so far, because it seems like a lot of work, with no urgent need. Imposing 15 minutes timeouts is now actually such an urgent need... :-)
Actually, when we opened it, things were more complex - our long- running command could require interaction with the user (via stdin), and our cockpit plugin provided means to do that. Now we do not need this anymore, so can probably do this ourselves. But I think it would be useful if cockpit provides means to reconnect also to an interactive command. Basically, screen/tmux -style.
Thanks and best regards,
Regards, Katerina
On Mon, Mar 30, 2020 at 12:12 PM Gal Zaidman gzaidman@redhat.com wrote:
Hi Cockpit developers,
I saw that on cockpit-209 Session timeouts were added with the default to 15 minutes of inactivity (https://cockpit-project.org/blog/cockpit-209.html). I think that this change is problematic because:
- The timeout is very short and it can cause unexpected behavior to users and cockpit packages.
- The timeout can only be configured in the /etc/cockpit.conf file, so it is hard for packages to configure it to fit to their behavior.
For example, we created a package for installing ovirt with cockpit UI, that installation can take a lot of time, it has different phases and logging out in the middle can cause problems. We prefer to avoid editing /etc/cockpit.conf because we don't want to run over user configuration (what to do when there is already cockpit.conf present?)
I want to suggest:
- Raising the timeout to 2 hours of inactivity, this seems reasonable.
- Provide a more flexible way of configuring the timeout, with an option to the manifest.json package file and/or with a cockpit API call.
Thanks _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste...
Hello Yedidyah,
Yedidyah Bar David [2020-04-01 10:22 +0300]:
I think that the gdm case is different. There, you lock the session, not logout. Right? If so, after re-entering the password, the admin has everything back there.
Correct. That should also be the case for cockpit, as pages (should) have no long-lived state by themselves -- the state that they show is always the system state. (Of course there's short-lived state like whether an expander is open, but that's not precious).
Also: Does Red Hat now by default configures sshd to logout sessions after 15 minutes? If not, what's the difference?
It doesn't, and we can certainly discuss whether to enable it by default. I will circle back to Steve and check that requirement.
However, that's really mostly unrelated to the actual issue that you are having -- even if we disable the timeout by default, a page really should not rely on a cockpit session being constantly connected for a long time. Network interfaces go down or roam, TCP timeouts happen, browsers crash, tabs get closed accidentally or get forgotten, batteries drain, people close/suspend their laptops.
The engine-setup process should not depend on cockpit session being around. It needs to run even when you log out of Cockpit and the user should be able to see the running process output when they log back in again.
OK, how? Do you have an example for a cockpit module/plugin/whatever that does that?
Yes, the "Apply software updates" (dnf update) is a very similar case. The actual operations are done in PackageKit, which is the local separate service on the target machine that actually does the upgrade. Cockpit just triggers it [1], and when the page loads it checks if there is an already running update [2].
[1] https://github.com/cockpit-project/cockpit/blob/master/pkg/packagekit/update... [2] https://github.com/cockpit-project/cockpit/blob/master/pkg/packagekit/update...
That runs a long-running command, saves its output somewhere, and if being logged out in the middle, allows the user to reconnect, showing everything since the last part already seen by the user? Does cockpit have means to help plugin authors do that, without reinventing the wheel every time?
Is "engine-setup" just a control frontend for some local service that does the actual setup? Then something similar like Software Updates should be possible.
Or is it all a single CLI that needs to run all the time, and will crash if its terminal goes away? Then a simple way how to "detach" this is systemd-run(1). You could use a fixed unit name, like `--unit cockpit-ovirt-engine-setup`, which will give you that:
* On page load, you check if that unit exists, and if so, you can show "installation in progress" (the "resume" part). If you want to show the previous logs on the page, you can get it with `journalctl -u cockpit-ovirt-engine-setup`.
* If that unit does not exist, then there's no running install, and you can start one. You can then stream the output with `journalctl -u cockpit-ovirt-engine-setup -f`.
If it helps, we can certainly write an example page that does that. There's nothing else in cockpit or related projects that starts long-running processes, so I have no existing examples to point to.
Or is engine-setup by and large an Ansible script? Maybe there is some existing service out there that can run/control playbooks, kind of like a lightweight Ansible Tower. If not, systemd-run ansible-playbook is just a special case of the above.
Actually, when we opened it, things were more complex - our long- running command could require interaction with the user (via stdin), and our cockpit plugin provided means to do that. Now we do not need this anymore, so can probably do this ourselves.
That certainly helps a lot indeed.
But I think it would be useful if cockpit provides means to reconnect also to an interactive command. Basically, screen/tmux -style.
systemd can do all the hard work for that already, but we can certainly provide some helpers for that. This is just the first time ever that we hear about that demand, so we don't have a pre-made cake yet, sorry :)
Thanks!
Martin
On 02.04.20 12:02, Martin Pitt wrote:
Hello Yedidyah,
Yedidyah Bar David [2020-04-01 10:22 +0300]:
I think that the gdm case is different. There, you lock the session, not logout. Right? If so, after re-entering the password, the admin has everything back there.
Correct. That should also be the case for cockpit, as pages (should) have no long-lived state by themselves -- the state that they show is always the system state. (Of course there's short-lived state like whether an expander is open, but that's not precious).
Also: Does Red Hat now by default configures sshd to logout sessions after 15 minutes? If not, what's the difference?
It doesn't, and we can certainly discuss whether to enable it by default. I will circle back to Steve and check that requirement.
Hmmm. I don't understand why we would do that.
The security exectation is that any UI (such as GNOME or Windows) where a terminal and/or browser are shown have a lock screen.
Why would each session in a terminal or browser need to implement locking themselves?
And even if so, why would it be a default? Can we make Cockpit no log out by default, while still providing the option to configure it?
Stef
However, that's really mostly unrelated to the actual issue that you are having -- even if we disable the timeout by default, a page really should not rely on a cockpit session being constantly connected for a long time. Network interfaces go down or roam, TCP timeouts happen, browsers crash, tabs get closed accidentally or get forgotten, batteries drain, people close/suspend their laptops.
The engine-setup process should not depend on cockpit session being around. It needs to run even when you log out of Cockpit and the user should be able to see the running process output when they log back in again.
OK, how? Do you have an example for a cockpit module/plugin/whatever that does that?
Yes, the "Apply software updates" (dnf update) is a very similar case. The actual operations are done in PackageKit, which is the local separate service on the target machine that actually does the upgrade. Cockpit just triggers it [1], and when the page loads it checks if there is an already running update [2].
[1] https://github.com/cockpit-project/cockpit/blob/master/pkg/packagekit/update... [2] https://github.com/cockpit-project/cockpit/blob/master/pkg/packagekit/update...
That runs a long-running command, saves its output somewhere, and if being logged out in the middle, allows the user to reconnect, showing everything since the last part already seen by the user? Does cockpit have means to help plugin authors do that, without reinventing the wheel every time?
Is "engine-setup" just a control frontend for some local service that does the actual setup? Then something similar like Software Updates should be possible.
Or is it all a single CLI that needs to run all the time, and will crash if its terminal goes away? Then a simple way how to "detach" this is systemd-run(1). You could use a fixed unit name, like `--unit cockpit-ovirt-engine-setup`, which will give you that:
On page load, you check if that unit exists, and if so, you can show "installation in progress" (the "resume" part). If you want to show the previous logs on the page, you can get it with `journalctl -u cockpit-ovirt-engine-setup`.
If that unit does not exist, then there's no running install, and you can start one. You can then stream the output with `journalctl -u cockpit-ovirt-engine-setup -f`.
If it helps, we can certainly write an example page that does that. There's nothing else in cockpit or related projects that starts long-running processes, so I have no existing examples to point to.
Or is engine-setup by and large an Ansible script? Maybe there is some existing service out there that can run/control playbooks, kind of like a lightweight Ansible Tower. If not, systemd-run ansible-playbook is just a special case of the above.
Actually, when we opened it, things were more complex - our long- running command could require interaction with the user (via stdin), and our cockpit plugin provided means to do that. Now we do not need this anymore, so can probably do this ourselves.
That certainly helps a lot indeed.
But I think it would be useful if cockpit provides means to reconnect also to an interactive command. Basically, screen/tmux -style.
systemd can do all the hard work for that already, but we can certainly provide some helpers for that. This is just the first time ever that we hear about that demand, so we don't have a pre-made cake yet, sorry :)
Thanks!
Martin _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste...
Hello all,
Stef Walter [2020-04-02 12:54 +0200]:
It doesn't, and we can certainly discuss whether to enable it by default. I will circle back to Steve and check that requirement.
Hmmm. I don't understand why we would do that.
The security exectation is that any UI (such as GNOME or Windows) where a terminal and/or browser are shown have a lock screen.
Why would each session in a terminal or browser need to implement locking themselves?
As far as I understood it: Because it's another security boundary. In almost every case, the Cockpit page has different or more credentials than the rest of the desktop session. It's effectively an open root shell (→ sudo tickets usually time out after 10 or 15 mins by default), or even a shell on a remote system. So it's similar why e. g. bank web sites log you out after a few minutes of inactivity.
I'm actually mildly in favor of keeping the locking by default, but if there is good arguments to *not* lock by default, I can certainly be convinced. As I said, I'd first like to circle back with Steve whether not locking by default is acceptable for CC certification.
And even if so, why would it be a default? Can we make Cockpit no log out by default, while still providing the option to configure it?
Technically yes, of course.
Martin
Hello all,
Martin Pitt [2020-04-02 13:06 +0200]:
I'm actually mildly in favor of keeping the locking by default, but if there is good arguments to *not* lock by default, I can certainly be convinced. As I said, I'd first like to circle back with Steve whether not locking by default is acceptable for CC certification.
And even if so, why would it be a default? Can we make Cockpit no log out by default, while still providing the option to configure it?
Technically yes, of course.
Just to close the loop for the archives: This happened in version 218: https://cockpit-project.org/blog/cockpit-218.html
Martin
Hello all,
Yedidyah Bar David [2020-04-01 10:22 +0300]:
The suggested 2h is just too much. The engine-setup process should not depend on cockpit session being around. It needs to run even when you log out of Cockpit and the user should be able to see the running process output when they log back in again.
OK, how? Do you have an example for a cockpit module/plugin/whatever that does that? That runs a long-running command, saves its output somewhere, and if being logged out in the middle, allows the user to reconnect, showing everything since the last part already seen by the user? Does cockpit have means to help plugin authors do that, without reinventing the wheel every time?
I finally got around to creating such an example:
https://github.com/cockpit-project/cockpit/pull/14318
Comments appreciated!
Pitti
+Nir Levy nlevy@redhat.com and +Aviv Turgeman aturgema@redhat.com FYI
Il giorno lun 6 lug 2020 alle ore 12:39 Martin Pitt martin@piware.de ha scritto:
Hello all,
Yedidyah Bar David [2020-04-01 10:22 +0300]:
The suggested 2h is just too much. The engine-setup process should not depend on cockpit session being around. It needs to run even when you log out of Cockpit and the user should be able to see the running process output when they log back in again.
OK, how? Do you have an example for a cockpit module/plugin/whatever that does that? That runs a long-running command, saves its output somewhere, and if being logged out in the middle, allows the user to reconnect, showing everything since the last part already seen by the user? Does cockpit have means to help plugin authors do that, without reinventing the wheel every time?
I finally got around to creating such an example:
https://github.com/cockpit-project/cockpit/pull/14318
Comments appreciated!
Pitti
cockpit-devel@lists.fedorahosted.org
-
Gal Zaidman -
Katerina Koukiou -
Martin Pitt -
Martin Pitt -
Sandro Bonazzola -
Stef Walter -
Yedidyah Bar David