Quoth Niels M�ller: > Well, it could refuse to create any files by default.
This is the boring solution, but perhaps as good as any. > And then have some mechanism for making exceptions to this rule. An > example of such a mechanism (which I don't know if it makes sense): If > the directory is writable by no-user processes, and if it has the > setuid bit set, then the no-user process can create files, and the > created files get the same owner as the directory. Would this actually make any difference compared do what we have today? Anybody would still be able to write to the directory by doing an rmauth, potentially filling up the partition or altering data. I would say that since login groups are non-persistant, you should never give the no-user write access to anything more important than /tmp/ on the disk, as this is effectively the same as giving the same access for "other" (you cannot give access for "the bind process running as no-user", "the no-user that was previously root", or "the no-user with this login group ID" and since anybody can go no-user, no-user access is world access). Thinking more about this, I can't see any secure way you could let a no-user process store data to be retrieved on restarting the process, except opening the files before going no-user. I also see very little reason for the fourth set of permissions in the filesystem, as this is in most cases the same as "other" (exception is when other has more access than group, and your user are in the group). IOW, apache running its threads as no-user would be OK, a read-only, passive only anonymous ftp server could run as no-user, but in many (most?) cases, this can not replace running as a dedicated user. On the other hand, there is the possibility that it would help security if one wrote applications to do "difficult" stuff (like parsing) in no-user processes, sending the results back through pipes or socketpairs opened before the fork(). Oystein -- When in doubt: Recompile.
