[2016-12-20 22:10] Russ Allbery <r...@debian.org> > Hm, transient IDs is an interesting idea. In a lot of cases, we create a > system user just to isolate the running daemon, not to control file system > access. The drawback, though, is that one has to have a really clear idea > of what resources the process would need in order to make sure this is > safe. (A much clearer idea than the understanding we need to know when > it's safe to delete a system user, I think.)
You just gave me good idea. What about not removing $HOME, but chowning it to root? I mean, on install we create user and if its $HOME already exists, just chown it. Unfortunately, it does not answer the question what to do with files outside of $HOME. > Using random high-numbered IDs, while appealing, probably isn't a great > idea because we allow the local admin to use that space. It's possible > that they're doing something that's consuming millions of IDs for some > reason, so although there's a lot of space there, we can't entirely rule > out the possibility of a conflict. Although we could probably carve out > more space if we really needed to. 2 ^ 32 = 4 294 967 296. Probably we can reserve several millions for such non-recycle usage. So far my summary: - wasting system UIDs is bad. We have only 900 of them - so far we have no satisfactory solution to UID wasting - transient UIDs are no solution, but can reduce wasting - seems worth trying to implement transient UIDs and see, how well they are applicable. -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff | is urgent, you have my phone number.
pgpYVHxqoJ8io.pgp
Description: PGP signature
