Skip to content

add notes to create an emergency user #1703

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 19 commits into from
Feb 17, 2025
Merged
Show file tree
Hide file tree
Changes from 7 commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/backend/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ security
sending-email
subscribers
traversal-acquisition
users-groups
users-groups/index
vocabularies
widgets
workflows
Expand Down
13 changes: 0 additions & 13 deletions docs/backend/users-groups.md

This file was deleted.

64 changes: 64 additions & 0 deletions docs/backend/users-groups/emergency-user.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
---
myst:
html_meta:
"description": "Create an emergency user"
"property=og:description": "Create an emergency user"
"property=og:title": "Create an emergency user"
"keywords": "Plone, users, groups, emergency user, pip, buildout"
---

(user-groups-emergency-user-label)=

# Emergency user

An emergency user is one that you can use to regain administrative access to a Plone site.
If you lose the administrator password, or you inherit a project without proper documentation, you can create an emergency user.

First of all, do the following steps not in a production environment!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would someone do in a Production environment? Are they out of luck?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, you can do this operations in a production env, but you should not do this. ;-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should someone do in production instead? We can't say "don't do this", then in the next section say "do this". It's very confusing.

Perhaps you can include what are the consequences and risks of doing this in production, aside from the obvious, specifically that the site will be down while adding the emergency user.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@1letter can you answer the following questions? I want to move this PR forward.

  1. What should someone do in production instead?
  2. If someone does this in production, what are the risks?
  3. In which environments is it OK to do this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I addressed these issues with #1854

I decided to talk about "Zope Manager Users", which IMO it is more appropriate than "Emergency users"
I added a note about taking in to account the security implication of adding a Zope manager user.

Copy link
Contributor

@acsr acsr Feb 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ale-rt @stevepiercy I like the change to extend the scope to "Zope Manager Users" and mention the "Emergency user", but the traditional term "Emergency user" should be highlighted in the text to reflect the purpose in production!

I added this here, because of the context of the suggestion by @stevepiercy in my discussions with him and seperately with @jensens.

But it needs to be seen also in context of the current preview:
https://plone6--1703.org.readthedocs.build/admin-guide/add-emergency-user.html

I would also enhance two things:

1. Do not tag admin:admin "as usual":

It is OK to use that for an instance fired up for testing and to be destroyed at once or soon or later before going to production. But it should be mentioned and made clear that for instances installed ending in production the password should be changed before anything goes into persistence. The consequences might be not obvious, but even behind a proxy the ZMI root may be reachable (like with Volto) and can lead to a permanent backdoor not easy to discover even not using admin:admin.

Imagine a different user:password than admin/admin and the sysadmin / integrator changes and the httpauth in the ZMI backend is not changed or restored from a backup. Then an in fact unauthorízed person can try to gain access with these hardcoded credentials.

2. Prominent warning to immediately change default credentials

There should be a prominent warning

  • to immediately change these credentials and
  • pack the database before going into production.

Further considerations

3. @1letter completely denied to use this in production.

I am contrary because the emergency user purpose is still valid for emergency use cases like changed admins or lost credentials. The Challenge in production is, that the user is persistent in the database and therefore also in backups. So old backups are still accessible with the old credentials when restored without proper awareness and documentation of changes in access credentials including point in time.

4. Revamp random password as default

In the past there was an approach that the installers created a random password and wrote it into the filesystem when the initial password was not specified during install.

When you removed the file, took a note in your password manager and changed the password at once no traces were left. Today these ways are deeply buried in e.g. docker containers and not easy to handle.

Maybe this is a trap in automated deployments

ongoing work on this

I am working on writing this up for cookieplone based docker deployments, but it is too early and would block the release of this PR. This can be added later.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The traditional term "Emergency user" should be highlighted in the text to reflect the purpose in production!

Do you have suggestion on how to do that?

So old backups are still accessible with the old credentials when restored without proper awareness and documentation of changes in access credentials including point in time.

Uhm maybe here I am missing something. When you have access to the DB you can anyway change the password manually there. So I do not consider this a real issues.

In the past there was an approach that the installers created a random password and wrote it into the filesystem when the initial password was not specified during install.

I think this is extending the scope of this PR.

I am working on writing this up for cookieplone based docker deployments, but it is too early and would block the release of this PR. This can be added later.

Agreed!

Copy link
Contributor

@acsr acsr Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So old backups are still accessible with the old credentials when restored without proper awareness and documentation of changes in access credentials including point in time.

@ale-rt The issue in my deployments was in place because the Cookieplone project template sets up a Traefik that creates a basicauth middleware and is created by a label in the docker swarm stack service backend.

In my early attempts I tried to modify the deployment in the docker-compose.yml file, but the changes had no effect and seemed to be ignored in the redeployment.

Today @pbauer, @tlotze and me went through the training docs for the deployment and weeded out lots of pitfalls in order of execution and issues related to images missing on the arm platform for servers.

During these attempts it became clear that the initial modifications during setup were rolled out into the yml file in devops/stacks/ named after the hostname. Making the changes in this file allows to change the http basicauth of the middleware that overrides the password of the actual ZMI user "admin". Other additional Zope admins or so called "emergengy users" were not affected. The ZMI "admin" users password could be changed successfully in the ZMI but had no effect in this setup behind Traefik. Keep in mind that this user has an ID admin and a seperate name admin that can be changed and should not be mixed up.

That said, the origin of the "persistent" basicauth is discovered and therefore the Cookieplone docs needs to be updated to point to the place for changing that.



(user-groups-create-an-emergency-user-label)=

## Create an emergency user

There are two procedures to create an emergency user, depending on how you created and manage the Plone site.
For both scenarios, the commands you run will stop the Plone site, add a new user, and start the Plone site.

```{important}
You should always stop your Plone site before adding a new user.
```

```{important}
The new username must not be an existing one.
Therefore you should avoid the username `admin`, but use another arbitrary name, such as `admin2`.
```


(user-groups-emergency-user-pip-installation-label)=

### pip based Plone instance

You can run the following shell commands to create an emergency user.

```shell
./venv/bin/instance stop
./venv/bin/addzopeuser -c instance/etc/zope.conf <user> <password>
./venv/bin/instance start
```

Now you can login with the created user.


(user-groups-emergency-user-buildout-installation-label)=

### Buildout based Plone instance

With buildout and `plone.recipe.zope2instance`, you can run the following shell commands to create an emergency user.

```shell
bin/instance stop
bin/instance adduser <user> <password>
bin/instance start
```

Now you can login with the created user.
20 changes: 20 additions & 0 deletions docs/backend/users-groups/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
---
myst:
html_meta:
"description": "Managing users and groups in Plone"
"property=og:description": "Managing users and groups in Plone"
"property=og:title": "Managing users and groups in Plone"
"keywords": "user, groups, Plone"
---

(backend-users-groups-label)=

# Users and groups


```{toctree}
:caption: Users and groups
:maxdepth: 2

emergency-user
```