On Fri, 26 Jul 2002, Dave Hill wrote: > I have just upgraded from 2001a to 2002.RC2 and have decided to use the > restrictBox functionality to restrict access to the system. > > Unfortunately, one of our users has just said that he can no longer access > a mailbox called "Archive/~foo". > > It appears that the parser doesn't differentiate between "~" at the > beginning (like ~user/Archive) and somewhere in the middle (like the above > scenario).
This is correct. restrictBox is extremely paranoid in what it will accept; it disallows any occurance of "..", "//", or "/~". Of course, this also disallows names which may be perfectly acceptable in a proper UNIX filesystem. The concern is that we are seeing filesystems which are not proper UNIX filesystems being made accessible to UNIX systems, and thus strings which are alright in proper UNIX may not be "alright" in those filesystems. Do we really know that the filesystem does not treat embedded .. (or ...) specially? Do we really know that the filesystem resolves foo//bar to foo/bar and not /bar? Do we really know that the filesystem resolves foo/~bar to foo/~bar and not ~bar? Yes, a proper UNIX filesystem does the right thing. But not every filesystem is proper UNIX any more. We've had unfortunate experiences with assumptions that were completely trustworthy in 1992 being invalidated in 2002, and being told that it was our fault for not knowing about a 1999 document which could be construed as retroactively redefining the 1992 world. It seemed easier, more straightforward, and safer to disallow all such names rather than to make assumptions about certain names being valid only to find out the hard way that it's an invalid assumption in some future system. More importantly, it seemed better to reject such names now, rather than allow them and later on have to add a rejection because the name creates a security bug with mounted Windows Blurdybloop filesystems. Better to suffer the pain once than many times... :-) Of course, sites can modify the code in mailboxfile() in env_unix.c to relax these restrictions, or make them smarter. I'm not adamant about the current behavior. I would be willing to change it if a patch was offered along with a convincing case that it will always be safe. But remember, please don't think about what is safe with proper UNIX filesystems. Think about Windows Blurdybloop in the year 2013. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
