On Mon, Nov 03, 2014 at 10:49:24AM -0800, Eric Rannaud wrote: > On Mon, Nov 3, 2014 at 9:06 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > >> That doesn't help because we explicitly reject O_RDONLY when combined > >> with O_TMPFILE. > > > > I think I'm missing something. How is an O_RDONLY temporary file > > useful? Wouldn't you want an O_RDWR tempfile with mode 0400 or > > something like that? > > Isn't it because they are essentially emulating an atomic open() > capable of creating a file with inherited ACLs, according to > relatively complex rules? open *can* be used with O_CREAT|O_RDONLY > (touch(1) might do that), which would naively translate into: > > fd = open(dir, O_TMPFILE|O_RDONLY, 0600) > fsetxattr(fd, "...") > fsetxattr(fd, "...") > linkat(AT_FDCWD, "/proc/self/fd/...", ..., AT_SYMLINK_FOLLOW) > return fd; > > Now this would be happening on the server, and the only reason why it > would be important to ensure that fd is O_RDONLY, is that smbd does > not do its own bookkeeping of how each file handle was opened, and > would rather have the kernel enforce O_RDONLY? > > With O_TMPFILE as implemented now, smbd would have to do open(dir, > O_TMPFILE|O_RDWR, 0600), but internally keep track that O_RDONLY was > requested by the client on that fd, and block any writes to fd itself. Which we already do, actually.. Although the atomic open emulation is a very interesting idea for us. That's something we currently don't do correctly across different protocols (although we do it between smbd's themselves). Jeremy. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
