> All this complexity of trivial things (just open a temp file) is one > of the reasons I think the whole idea of /tmp is a fundamental > misdesign and eventually one should be able to chmod it to 755 (while > programs should use per-user TMPDIRs). Maybe I'm a little off this morning, but even per-user TMPDIR's aren't a very good solution. So you make a tmp directory somewhere for each user (technically I don't think it matters where) and set the directory permissions so that only that user has read/write/execute. Yes, that will stop other users from creating symlinks and such and waiting to trap innocent users. But, If all the programs Joe user runs now creates files in /usr/home/joe/tmp and one of the programs is suid root and is vulnerable to a symlink attack then no other users can abuse that program... except Joe. Joe can still symlink attack programs because he controls all the files in his tmp directory. I suppose he could even do a pipe attack against himself (as described in the gcc post earlier), but for that to be worth while it would have to be a suid program thinking it was a trusted pipe it was reading trusted data from...anyway If programs create files in their effective user id tmp space (ie Joe runs a suid root program so it creates files in /root/tmp) then Joe couldn't abuse the symlinks, but now we are forcing programs to open and write to files as root, rather than at least trying to convince authors to give away permissions and open and write as the user. I think this would be a very bad thing. Perhaps there should be a new Temp Filesystem that creates temp files off in an untouchable area like the proc filesystem. Only programs that call mktemp get a filehandle in there, no symlinks allowed. Of course, this would have to be handled at the kernel level... but done properly it could eliminate a gob of poorly written code. Pro's con's caveats? Kill9 (ducking for cover)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:33 PDT