Skip to content
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

Decide how to manage system accounts #1

Open
giomasce opened this issue Mar 16, 2013 · 6 comments
Open

Decide how to manage system accounts #1

giomasce opened this issue Mar 16, 2013 · 6 comments

Comments

@giomasce
Copy link
Member

This package creates two users (cms and isolated, with groups cms and isolate) during installation. Policies about how to manage system users have never been completely clarified in Debian (see pointers below), but:

  • I'd like using some tricks to avoid name collisions with real users. The two more widely used alternatives are prepending an underscore or prepending Debian-. I prefer the first one.
  • It is suggested not to delete the users, even after purging, in order to avoid that other unrelated system users may access files left over. I'm undecided whether to follow or not this suggestion. Of course we have to clean up and lock accounts anyway.

Pointers:

(along with merged bugs).

What do we want to do?

@bblackham
Copy link
Contributor

Secondary to this, isolate actually uses the UID = 60000 + box_id, with box_id \in [0,100). CMS sets box_id = shard number. I'm not sure how to sanely reserve a range of accounts.

(User namespaces, maybe landing in the 3.10 kernel, may help to address that issue in isolate, so that only a single extra uid is required. Perhaps we can just sit on this secondary issue until it becomes irrelevant).

@giomasce
Copy link
Member Author

Il 16/03/2013 13:34, Bernard Blackham ha scritto:

Secondary to this, isolate actually uses the UID = 60000 + box_id,
with box_id \in [0,100). CMS sets box_id = shard number. I'm not sure
how to sanely reserve a range of accounts.

But then, what is the user isolate used for? Is it really needed? (of
course the group is, but could we have the group without the user?)

OTOH, I'm actually also unsure whether the group cmsuser (which is not
cms, as I incorrectly wrote above) is really required.

Gio.

Giovanni Mascellani [email protected]
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: [email protected] / [email protected]

@stefano-maggiolo
Copy link
Member

I always thought that the group cmsuser was needed but not the user. Am I wrong?

@giomasce
Copy link
Member Author

Il 16/03/2013 13:45, Stefano Maggiolo ha scritto:

I always thought that the group cmsuser was needed but not the user. Am I wrong?

Well, it depends on how you use them. Anyway, I'm pretty sure at least
one of them is not required...

Gio.

Giovanni Mascellani [email protected]
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: [email protected] / [email protected]

@bblackham
Copy link
Contributor

@giomasce wrote:

But then, what is the user isolate used for? Is it really needed? (of course the group is, but could we have the group without the user?)

@stefano-maggiolo wrote:

I always thought that the group cmsuser was needed but not the user. Am I wrong?

I should probably have explained more somewhere. The packages create the following users/groups:

  • The isolate package creates the isolate group. Any users in this group are allowed to run isolate. (We use the POLA, given that isolate runs suid-root).
  • The isolate package also creates the isolated user and group, which isolate uses to run "isolated" (sandboxed) binaries. The UID matches the one hard-coded into isolate (but only when box_id == 0, as per the issue in comment 2).
  • The cms package creates the cmsuser user and group.
    • The package adds an upstart script which runs CMS on boot. This script executes CMS as cmsuser:cmsuser.
    • cmsuser is also added to the isolate group.
    • All files under /var/{lib,cache,log}/cms are owned by cmsuser.

@bblackham
Copy link
Contributor

I think what the package currently does (deleting all users on removal) is mostly sane, because:

  • the isolated user/group is ephemeral. It is only used for files in /tmp/box while the sandbox is executing. It can be safely deleted when the isolate package is also deleted.
  • the isolate group is only ever used as the GID of /usr/bin/isolate. It can be safely deleted too.
  • the cmsuser user and group are more widely used - the files in /var/{lib,cache,log}/cms are owned by this user. However, the purge action on the postrm script removes these directories. I don't think CMS puts files anywhere else, so I would say that this user/group can also safely deleted on purge. But this one I'm less convinced about, as end users may just randomly chown -R cmsuser <stuff>. Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants