lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 2 Feb 2007 08:45:27 +0100 From: Andi Kleen <ak@...e.de> To: suparna@...ibm.com Cc: Trond Myklebust <trond.myklebust@....uio.no>, Zach Brown <zach.brown@...cle.com>, linux-kernel@...r.kernel.org, linux-aio@...ck.org, Benjamin LaHaise <bcrl@...ck.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH 4 of 4] Introduce aio system call submission and completion system calls > Isn't that kind of information supposed to be captured in nfs_open_context ? > Which is associated with the open file instance ... Or a refcounted struct cred. Which would be needed for strict POSIX thread semantics likely anyways. But there never was enough incentive to go down that path and it would be likely somewhat slow. > > I know this has been a traditional issue with network filesystems, and I > haven't kept up with the latest code and decisions in that respect, but how > would you do background writeback if there is an assumption of running in > the context of the original submitter ? AFAIK (Trond will hopefully correct me if I'm wrong) in the special case of NFS there isn't much problem because the server does the (passive) authentication and there is no background writeback from server to client. The client just does the usual checks at open time and then forgets about it. The server threads don't have own credentials but just check those of others. I can't think of any cases where you would need to do authentication in the client for every read() or write() Overall the arguments for reusing current don't seem to be strong to me. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists