| 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
| ||
|
Message-ID: <18232.54549.271030.214405@notabene.brown> Date: Tue, 13 Nov 2007 09:35:01 +1100 From: Neil Brown <neilb@...e.de> To: "J. Bruce Fields" <bfields@...ldses.org> Cc: nfs@...ts.sourceforge.net, linux-kernel@...r.kernel.org Subject: Re: nfsd bugfixes (CC: trimmed - as Bruce says: separate discussion) On Monday November 12, bfields@...ldses.org wrote: > On Tue, Nov 13, 2007 at 09:08:42AM +1100, Neil Brown wrote: > > Calling nfsd_setuser an extra time does open us up for a very tiny > > possibility of an ENOMEM at an awkward time. > > Hm. Could you give an example of possible consequences? Just that you could get an ENOMEM in the middle of a NFSv4 COMPOUND. I guess that should result in NFSERR_RESOURCE and we just hope the client is able to cope and resend the remainder of the compound. Though looking at the code, ENOMEM becomes nfserr_dropit... does that mean the we would drop the whole request and the client would need to resend, possibly duplicating non-idempotent portions? Mainly, it just feels unclean. > > (Though note this is somewhat of a separate discussion, since this > particular patch doesn't add a call to nfsd_setuser().) Hmm, you are right, we already call nfsd_setuser in both paths, you we just adding the check for privileged port - doh ;-) NeilBrown - 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