user/dir mountpoint

[markus2330]

Goal

People new to Elektra usually expect/assume that a user (non-root) must be able to mount a user/dir mountpoint. I think they are right with their expectation but there are important details to be considered first.

Ideas

1. kdb mount -N to decide where it is mounted, e.g. kdb mount -N user /hello is the mountpoint /hello only for the user who mounts. And user is default except when root is doing it.
2. keep it as it is, and only add flag --as-user which is suggested when mounting fails
3. by default mount in user (except if root does it), to override use: kdb mount --in-system file.x user/x
4. make flag system/elektra/security/mountpoints/user/enable that controls if user/dir mountpoints are enabled

Issues

• how can a admin prohibit mountpoints for a user?
• how can we avoid that a user injects malicious plugins?
• what are the semantics of cascading mounts? (for user/dir mountpoints)
• how to distinguish in the kdb util a user/dir mountpoint for only one user/dir vs. for every user/dir?
• what happens if mountpoints collide? (A user mounted user/a, the administrator mounts user/a without knowing that a user already has mounted user/a)

Related

#1080

Tasks

Are there additional problems not mentioned in the above list?

Please state your opinion how these issues should be solved.

[tom-wa]

i'd say the best solution would be to give each user another elektra.{ini,ecf} file and repeat the whole mounting process at startup for the user giving the users mountpoints priority over the administrators mountpoints (would be expected like with namespaces/configs). about the security, i think (for now) the file permissions are sufficient, but maybe adding metadata with permissions to mountpoints and letting elektra handle some of them would be an good idea for the future.

i have no idea how complicated the implementation would would get for that though.

[markus2330]

@krit0n kdb mount -N <where> to decide where it is mounted, e.g. kdb mount -N user /hello is the mountpoint /hello only for the user who mounts. And user is default.

[markus2330]

See also #1080 about expections for dir/ mountpoints.

Maybe user/ mountpoints should be in user/elektra and dir/ mountpoints in dir/elektra?

[markus2330]

I assume, the solution here would be to not just use system:/elektra/mountpoints but also user:/elektra/mountpoints and dir:/elektra/mountpoins. With a dir:/ mountpoint overriding a user:/ one and a user:/ mountpoint overriding a system:/ one.

Exactly! Probably, however, there are use cases where admins do not want users to overwrite their configs (KIOSK mode). If this can be ensured is unclear, though.

user:/elektra/mountpoints should only be allowed to define user:/ and dir:/ mountpoints. Similarly, dir:/elektra/mountpoints should only contain dir:/ mountpoints. Cascading mountpoints are automatically limited in this way.

If the admin has some way to ensure to get what (s)he wants, such limitations are maybe not necessary. If the admin does not impose any restrictions it would be fine if a user completely remounts all namespaces as needed.

But your proposal also sounds sensible.

What about spec:/ mountpoints in user:/elektra/mountpoints or dir:/elektra/mountpoints?

spec:/ is from permission level like system:/. Especially for spec:/ there might be users who want to remount sthg, e.g. to allow user-specific installations of software.

A user injecting malicous plugins cannot be prevented

This can be even done without mounting (put a plugin with same name as some other plugin to LD_LIBRARY_PATH).

[kodebach]

If the admin has some way to ensure to get what (s)he wants, such limitations are maybe not necessary. If the admin does not impose any restrictions it would be fine if a user completely remounts all namespaces as needed.

Overriding a part of system:/ with a user:/ mountpoint is conceptually weird. Moreover, it doesn't really have a use case. Applications should always use cascading lookups, so just adding a user:/ mountpoint should be totally fine. Also a big problem is how the resolver would work. For a system:/ mountpoint defined in user:/ the resolver would still return a file in a place the user probably doesn't have access to.

The spec:/ namespace is another problem. My opinion is still that spec:/ should be defined by application developers and shouldn't be touched by admins or users. However, the use case of user-specific apps (e.g. installing an app into ~/.local/bin) is definitely an important one. The problem here is that the spec for such an app should be placed into e.g. /etc, but instead into e.g. ~/.local/share. The current resolver has no support for this. I'm not even sure how we could support this without a new namespace (something I would like to avoid, since it significantly complicates the spec plugin or requires a "cascading spec lookup"). We would probably need a new resolver plugin.

A new resolver plugin (or a config option for the existing one to enable a mode) that always returns files in the users home directory would be solution to both problems.

[markus2330]

Yes, I agree with a "user-resolver for all namespaces" you probably get better what you want in the install an application to $HOME scenario (or any $DIR for parallel installs of the same user, as needed for devs). To make it work, we nevertheless need spec: and cascading mountpoints in user: and dir: (but system: would also end up in $HOME due to the user-resolver). We probably (hopefully) have someone else to work on the resolver and spec stuff.

Can you sum up what we talked about in the decision of #3693? I think you can remove the previous decision and only write what you plan to do now.

[kodebach]

Can you sum up what we talked about in the decision of #3693?

Will do

[markus2330]

@kodebach will this be part of #3693?

[kodebach]

The part about reading user:/elektra/mountpoints and dir:/elektra/mountpoints could be implemented as part of #3693 yes. The rest, especially the resolver changes should probably be a separate PR after that.

[stale]

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue/PR with the remainder of this issue/PR.
Thank you for your contributions 💖

[markus2330]

@kodebach would be great to see this!

[kodebach]

Yes, would be great, but doesn't fit with my thesis topic at all and I don't have unlimited time.

[markus2330]

Ok, lets see maybe someone wants it as project. It should be quite easy to do compared with other projects? It is only some barrier to dive into the code and it is C...

[kodebach]

It should be quite easy to do compared with other projects?

Calling this "easy" is a bit of a stretch... It might be easier than some other projects, but there are certainly much easier things. Just making /elektra reserved and reading user:/elektra/mountpoints and dir:/elektra/mountpoints is not that hard, but there are some open questions in this issue already. Also this seems like prime example of an issue where more and more questions will appear during implementation.

[github-actions]

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

[github-actions]

I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖