On Fri, 25 Jul 2003 19:33:25 -0600, Dwayne C. Litzenberger wrote: > On Sat, Jul 26, 2003 at 09:16:44AM +1000, Matthew Palmer wrote: >> > Not necessarily. With the current /tmp system, the only directory >> > entries that are created are the ones that are actually needed at any >> > given time. If we switch to /tmp/username, then there will be a >> > directory entry in /tmp for *every user* who ever logs on. >> >> Hang about. You seem to have two different systems running here. One >> where files get cleaned out of /tmp sometimes, and one where they don't. >
> No, I'm not, actually. tmpreaper works by absolute time, like 7 days. > *Many* users can log into a system during that amount of time, but they > probably won't all be creating temporary files that they don't clean up > shortly after. With libpam-tmpdir, it doesn't matter whether the user > doesn't even have a home directory (i.e. system users, qmail users, > nobody, etc) -- they will all cause an entry to be created in /tmp/user. I'm having trouble imagining a system where the "working set" of active uids is so large that creating one directory for each of them stresses the filesystem. A machine with hundreds of users probably ought to use ext3 directory hashes, reiserfs or xfs. > Do I think using libpam-tmpdir by default would work? Yes, at least for > the short term. However, I also think it's a band-aid solution for the > real problem (excessive /tmp vulnerabilities), and it introduces problems > of its own. I think the real problem is the original misdesign of /tmp: requiring systems to have a world-writable directory, and making a large number of programs deal with the issues of world-writable directories was a horrible idea. Why make programs and users be careful when all they really want is some private scratch space? -- Martin