Re: CVS commit: src/tests/fs/common
On Tue, Mar 19, 2013 at 07:43:06PM +1100, matthew green wrote: The zfs tests are failing when run as an unprivileged user in thread_create() ... because default limit for threads (160) is too low ! When run as root, the limit value (2500) seems to be high enough. So should we increase the default limits? It's always a tough call to set limits for a large ensemble of hardware, big and small, but it also seems that limits should be big enough to run our test cases. i think the default thread limit should be more on the order of 1024 to 4096. Both the soft and hard limits for all the rlimits really need looking at. In most cases the hard limits are much too high! I'd have thought the soft thread limit should be relatively low (maybe more than 160), and the hard limit say 1024 (dunno really). Similarly for fds, maybe 256 and 4096. At the moment there are nice local-user DoS because of the hard limit values. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/tests/fs/common
On Sat, Mar 16, 2013 at 05:25:00AM +, Julio M. Merino Vidal wrote: Module Name: src Committed By: jmmv Date: Sat Mar 16 05:25:00 UTC 2013 Modified Files: src/tests/fs/common: h_fsmacros.h Log Message: Mark the zfs tests as requiring root. This is wrong. The zfs tests already use rump so they should not require root. However, I've already spent much more time than I wanted trying to figure out why that's the case without much luck. If you can find why, just remove this hack. The zfs tests are failing when run as an unprivileged user in thread_create() ... because default limit for threads (160) is too low ! When run as root, the limit value (2500) seems to be high enough. -- Nicolas Joly Biology IT Center Institut Pasteur, Paris.
Re: CVS commit: src/tests/fs/common
Nicolas Joly nj...@pasteur.fr writes: The zfs tests are failing when run as an unprivileged user in thread_create() ... because default limit for threads (160) is too low ! When run as root, the limit value (2500) seems to be high enough. So should we increase the default limits? It's always a tough call to set limits for a large ensemble of hardware, big and small, but it also seems that limits should be big enough to run our test cases. pgpmmHx2QH_Pf.pgp Description: PGP signature
Re: CVS commit: src/tests/fs/common
On Mon, Mar 18, 2013 at 09:13:35PM +0100, Nicolas Joly wrote: That make a 80 CPUs host require a thread limit value of 814 (=261+7*79) to be able to run this test. Sounds like a serious test case - Jukka.
Re: CVS commit: src/tests/fs/common
hi, On Thu, Jan 06, 2011 at 12:53:28AM +, YAMAMOTO Takashi wrote: (one nfsro test currently fails with EROFS vs. EACCES. Hopefully someone else can debate the correct errno) the NFS ACCESS procedure, which is used for open time permission checks, does not have a way to distinguish EROFS and EACCES. ie. EACCES is the expected behaviour in this case. Shouldn't the nfs client know that it's supposed to be readonly? probably. please feel free to fix it. :-) however, Or is this a case where the nfs client is read-write but the server isn't? i think so, yes. in this case, the client can't know EROFS at open time. YAMAMOTO Takashi -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/fs/common
hi, Module Name: src Committed By: pooka Date: Fri Dec 31 18:16:41 UTC 2010 Modified Files: src/tests/fs/common: h_fsmacros.h Log Message: Introduce r/o tests. They do two mounts: the first one is r/w and runs a generator which primes the fs. The second one is r/o and does the actual testing. Also, introduce a nfsro fstype which does a clientside r/w mount for a r/o server export. requested by yamt thanks. (one nfsro test currently fails with EROFS vs. EACCES. Hopefully someone else can debate the correct errno) the NFS ACCESS procedure, which is used for open time permission checks, does not have a way to distinguish EROFS and EACCES. ie. EACCES is the expected behaviour in this case. YAMAMOTO Takashi To generate a diff of this commit: cvs rdiff -u -r1.23 -r1.24 src/tests/fs/common/h_fsmacros.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/tests/fs/common
On Thu, Jan 06, 2011 at 12:53:28AM +, YAMAMOTO Takashi wrote: (one nfsro test currently fails with EROFS vs. EACCES. Hopefully someone else can debate the correct errno) the NFS ACCESS procedure, which is used for open time permission checks, does not have a way to distinguish EROFS and EACCES. ie. EACCES is the expected behaviour in this case. Shouldn't the nfs client know that it's supposed to be readonly? Or is this a case where the nfs client is read-write but the server isn't? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/fs/common
On Fri, Dec 31, 2010 at 07:45:26PM +, David Laight wrote: [...] From what I remember of the NFS protocol, the following 'rules' applied: 1) If you export part of a filesystem, you export all of the filesystem. that's probably trye 2) If you give anyone access, you give everyone access. 3) If you give anyone write access, you give everyone write access. these 2 are not true for NetBSD I think This is all because it is the 'mount' protocol that verifies whether a client has access - so a client that disobeys the mount protocol, or fakes up valid nfs file handles can avoid the access checks. This was true for the SunOS 4 nfs implementation (and maybe other implementations derived from the same base), but for NetBSD, some checks are done at the nfsd level: the source IP address from the NFS request is checked against the export list, as well as the R/O status for a write request (and other things such as the uid root is mapped to). So if you consider IP address are not spoofables in your environnement, IP-based access and write permissions are fine. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/tests/fs/common
On Sun, Jan 02, 2011 at 05:26:29AM +, David Holland wrote: On Sun, Jan 02, 2011 at 05:22:32AM +, David Holland wrote: It would also be worthwhile to test that nfsd doesn't allow writing via read-only handles, but that's a different issue and will require a different test framework that sends raw nfs packets. Hmm, no, maybe I misunderstood. Anyway, the mountd permissions issue is PR 3019, the longest-lived-without-attention bug in the whole bug database. Hm, yes the client side is expected to check for -ro mounts. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/tests/fs/common
On Sat, Jan 01, 2011 at 03:02:00PM +0200, Antti Kantee wrote: It is possible that netbsd's nfs server does additional checks but they are expensive to do on every nfs request. That's good advise to someone who is configuring an nfs server. ...which is to say, it's not relevant to this test; a readonly mount on the client should still be readonly regardless of what the server export permissions allow. It would also be worthwhile to test that nfsd doesn't allow writing via read-only handles, but that's a different issue and will require a different test framework that sends raw nfs packets. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/fs/common
On Sun, Jan 02, 2011 at 05:22:32AM +, David Holland wrote: It would also be worthwhile to test that nfsd doesn't allow writing via read-only handles, but that's a different issue and will require a different test framework that sends raw nfs packets. Hmm, no, maybe I misunderstood. Anyway, the mountd permissions issue is PR 3019, the longest-lived-without-attention bug in the whole bug database. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/fs/common
On Fri, Dec 31, 2010 at 06:16:41PM +, Antti Kantee wrote: Module Name: src Committed By: pooka Date: Fri Dec 31 18:16:41 UTC 2010 Modified Files: src/tests/fs/common: h_fsmacros.h Log Message: Introduce r/o tests. They do two mounts: the first one is r/w and runs a generator which primes the fs. The second one is r/o and does the actual testing. Also, introduce a nfsro fstype which does a clientside r/w mount for a r/o server export. requested by yamt (one nfsro test currently fails with EROFS vs. EACCES. Hopefully someone else can debate the correct errno) From what I remember of the NFS protocol, the following 'rules' applied: 1) If you export part of a filesystem, you export all of the filesystem. 2) If you give anyone access, you give everyone access. 3) If you give anyone write access, you give everyone write access. This is all because it is the 'mount' protocol that verifies whether a client has access - so a client that disobeys the mount protocol, or fakes up valid nfs file handles can avoid the access checks. It is possible that netbsd's nfs server does additional checks but they are expensive to do on every nfs request. David -- David Laight: da...@l8s.co.uk
