Hide admin user(name)s for mail managers

[girish]

@guyds You mean this for a UI/UX point of view as opposed to for security reasons, correct ?

[guyds]

@girish actually both.

Visually, because it doesn't make sense to show admin users to mail managers when they can't do anything with them.

But also security wise because in my opinion users with a lower access role (in this case mail managers) shouldn't know any (sensitive) details about users with a higher role (in this case admins), e.g. username, email address, ...
We all know passwords shouldn't be reused for different accounts/logins but I'm sure usernames are and therefore I think it's better to not show such data to others when that data isn't relevant for them.

[girish]

@guyds said in Hide admin user(name)s for mail managers:

But also security wise because in my opinion users with a lower access role (in this case mail managers) shouldn't know any (sensitive) details about users with a higher role (in this case admins), e.g. username, email address,

I see your point but the roles are not designed that way. The roles are designed to work in a trusting system and not designed for creating "spaces" / "bubbles" (similar to how we don't support domain level restrictions, cloudron is not designed for that).

The username is required to be known because when creating a mailbox you have to assign an owner. And if the username is something like cryptic like thegreatadmin, then it's helpful to go back and look at this user's info like full name and email to identify who this person is.

The username/email/name will also get ultimately leaked via LDAP in apps etc even if user is not the mail manager.

The UI can possibly hide the buttons but I do think it has to show the user's information.

[guyds]

@girish hmmm, I see, but imagine the following scenario:

Our clients come to us for developing a new Wordpress website and obviously they also want an integrated email system so they can send and receive mails for that website and probably they also want to see some analytics.
So we set up a separate cloudron for such client and install Wordpress for the website, SOGo (or one of the other webmail apps) for the email and Ackee for the analytics.

This means the cloudron is dedicated to the client and therefore the trusting factor is there since the client is the only party that makes use of the cloudron and its apps.

However, our clients aren't interested in administering the cloudron themselves so we will manage it for them. But they do want to be able to add extra email addresses when needed.
So the client will get the mail manager role while we are the admin of the system. In this scenario it doesn't make sense - and isn't even desirable - that the client can see our admin user.

So while I definitely understand your explanation, I hope you can see my point as well

[girish]

@guyds ah ok, that makes sense. In fact, we have discussed creation of 'service' user account type in the past. Such a user type is also useful to API/programmatic Cloudron access. These users will be hidden from LDAP and thus the apps also won't see them. Would such an idea make sense for your use case? For example, the superadmin account maybe has a 'service account' flag and it's not shown in user listing/mail owner/inside apps etc.

(Just an idea, have to refine it further).

[girish]

Here it is https://git.cloudron.io/cloudron/box/-/issues/771 . I had closed it before, looks like we have a better use case now to re-open it.

[guyds]

@girish That definitely sounds like an interesting solution, except that in my use case it's not (entirely) related to automation / programmatic access. So I guess it will also need some UI changes.

[andreasdueren]

@girish personally I would enjoy the option to limit the E-Mail manager to the groups they are part of. For example some clients use so little resources like only a website with E-Mail that it doesn’t make sense to give them a dedicated server but instead put a few on the same.

Now it would be nice if they could configure their own emails without being able to see let alone change the configuration of others.

[girish]

@andreasdueren said in Hide admin user(name)s for mail managers:

For example some clients use so little resources like only a website with E-Mail that it doesn’t make sense to give them a dedicated server but instead put a few on the same.

Noted... but that feature, for lack of a better term 'shared hosting' setup, has a lot of design implications. It's not just about hiding users but also resource allocation (storage/cpu/ram etc). Maybe someday

[micmc]

@andreasdueren said in Hide admin user(name)s for mail managers:

@girish personally I would enjoy the option to limit the E-Mail manager to the groups they are part of. For example some clients use so little resources like only a website with E-Mail that it doesn’t make sense to give them a dedicated server but instead put a few on the same.

Very good points as well, however as @girish says, as this would require to implement shared resources the idea is easier said than done. On the other hand, I personally can't see why it would not make sense to provide dedicated VPS at low cost for its own little resources needs to such client. In when you think about it, any client can grow and in such case the client is already set to scale without any more hassle. Cloudron is not too heavy for a simple basic use as it will adjust its own resources need only for the needs of the installed apps.

Now it would be nice if they could configure their own emails without being able to see let alone change the configuration of others.

Moreover, as explained previously if you install Cloudron for the client, a 10 bucks per month VPS would be more than perfect for such low needs, as superadmin you keep full control of the instance's management for the client and you give it admin privileges so it can fully manage its mail server. And with the upcoming multiple instances of Cloudron feature that should should become easier to manage from your side as well.