CVS commit: src/tests/fs/common
Module Name:src Committed By: mrg Date: Sat Oct 5 22:06:29 UTC 2019 Modified Files: src/tests/fs/common: fstest_nfs.c Log Message: sprintf->snprintf To generate a diff of this commit: cvs rdiff -u -r1.10 -r1.11 src/tests/fs/common/fstest_nfs.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/tests/fs/common
Module Name:src Committed By: mrg Date: Sat Oct 5 22:06:29 UTC 2019 Modified Files: src/tests/fs/common: fstest_nfs.c Log Message: sprintf->snprintf To generate a diff of this commit: cvs rdiff -u -r1.10 -r1.11 src/tests/fs/common/fstest_nfs.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/tests/fs/common/fstest_nfs.c diff -u src/tests/fs/common/fstest_nfs.c:1.10 src/tests/fs/common/fstest_nfs.c:1.11 --- src/tests/fs/common/fstest_nfs.c:1.10 Fri Feb 1 09:06:07 2019 +++ src/tests/fs/common/fstest_nfs.c Sat Oct 5 22:06:29 2019 @@ -1,4 +1,4 @@ -/* $NetBSD: fstest_nfs.c,v 1.10 2019/02/01 09:06:07 mrg Exp $ */ +/* $NetBSD: fstest_nfs.c,v 1.11 2019/10/05 22:06:29 mrg Exp $ */ /* * Copyright (c) 2010 The NetBSD Foundation, Inc. @@ -87,10 +87,12 @@ donewfs(const atf_tc_t *tc, void **argp, * First, we start the nfs service. */ srcdir = atf_tc_get_config_var(tc, "srcdir"); - sprintf(nfsdpath, "%s/../nfs/nfsservice/rumpnfsd", srcdir); - sprintf(ethername, "/%s/%s.etherbus", getcwd(cwd, sizeof(cwd)), image); - sprintf(ethername_ro, "%s_ro", ethername); - sprintf(imagepath, "/%s/%s", cwd, image); + snprintf(nfsdpath, sizeof nfsdpath, + "%s/../nfs/nfsservice/rumpnfsd", srcdir); + snprintf(ethername, sizeof ethername, + "/%s/%s.etherbus", getcwd(cwd, sizeof(cwd)), image); + snprintf(ethername_ro, sizeof ethername_ro, "%s_ro", ethername); + snprintf(imagepath, sizeof imagepath, "/%s/%s", cwd, image); nfsdargv[0] = nfsdpath; nfsdargv[1] = ethername;
CVS commit: src/tests/fs/common
Module Name:src Committed By: brad Date: Fri Aug 30 23:45:13 UTC 2019 Modified Files: src/tests/fs/common: fstest_lfs.c Log Message: The cleaner is compiled into the ATF test harness for the LFS filesystem tests. Use the new -J option to pass the raw device into the cleaner. This avoids the not rump safe getdiskrawname call and makes sure we use an internal rump device name for cleaning. This should fix bin/54488. To generate a diff of this commit: cvs rdiff -u -r1.6 -r1.7 src/tests/fs/common/fstest_lfs.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/tests/fs/common/fstest_lfs.c diff -u src/tests/fs/common/fstest_lfs.c:1.6 src/tests/fs/common/fstest_lfs.c:1.7 --- src/tests/fs/common/fstest_lfs.c:1.6 Sun Jan 20 14:50:58 2019 +++ src/tests/fs/common/fstest_lfs.c Fri Aug 30 23:45:13 2019 @@ -1,4 +1,4 @@ -/* $NetBSD: fstest_lfs.c,v 1.6 2019/01/20 14:50:58 gson Exp $ */ +/* $NetBSD: fstest_lfs.c,v 1.7 2019/08/30 23:45:13 brad Exp $ */ /*- * Copyright (c) 2010 The NetBSD Foundation, Inc. @@ -125,7 +125,7 @@ cleaner(void *arg) { char thepath[MAXPATHLEN]; struct lfstestargs *args = arg; - const char *the_argv[7]; + const char *the_argv[9]; char buf[64]; rump_pub_lwproc_newlwp(rump_sys_getpid()); @@ -139,14 +139,16 @@ cleaner(void *arg) the_argv[1] = "-D"; /* don't fork() & detach */ the_argv[2] = "-S"; the_argv[3] = buf; - the_argv[4] = args->ta_mntpath; - the_argv[5] = NULL; + the_argv[4] = "-J"; + the_argv[5] = thepath; + the_argv[6] = args->ta_mntpath; + the_argv[7] = NULL; /* xxxatf */ optind = 1; opterr = 1; - lfs_cleaner_main(5, __UNCONST(the_argv)); + lfs_cleaner_main(7, __UNCONST(the_argv)); rump_pub_lwproc_releaselwp();
CVS commit: src/tests/fs/common
Module Name:src Committed By: brad Date: Fri Aug 30 23:45:13 UTC 2019 Modified Files: src/tests/fs/common: fstest_lfs.c Log Message: The cleaner is compiled into the ATF test harness for the LFS filesystem tests. Use the new -J option to pass the raw device into the cleaner. This avoids the not rump safe getdiskrawname call and makes sure we use an internal rump device name for cleaning. This should fix bin/54488. To generate a diff of this commit: cvs rdiff -u -r1.6 -r1.7 src/tests/fs/common/fstest_lfs.c 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 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
> > 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. .mrg.
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
On Mon, Mar 18, 2013 at 02:57:27PM -0400, Greg Troxel wrote: > > Nicolas Joly 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. Another possibility would be to increase it locally, in the zfs test code. I just made some extra experiments with the following testcase : /usr/tests/fs/vfs/t_vnops:zfs_read_directory And it seems that the needed thread number is over 260 ... and depends on the number of virtual CPUs in the rump kernel which is the host CPUs number by default. RUMP_NCPU=1 ... ulimit -r 261 ... ok RUMP_NCPU=2 ... ulimit -r 268 ... ok RUMP_NCPU=3 ... ulimit -r 275 ... ok RUMP_NCPU=4 ... ulimit -r 283 ... ok [...] RUMP_NCPU=8 ... ulimit -r 310 ... ok RUMP_NCPU=9 ... ulimit -r 317 ... ok RUMP_NCPU=10 ... ulimit -r 324 ... ok [...] That make a 80 CPUs host require a thread limit value of 814 (=261+7*79) to be able to run this test. -- Nicolas Joly Biology IT Center Institut Pasteur, Paris.
Re: CVS commit: src/tests/fs/common
Nicolas Joly 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 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
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
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
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 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 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 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 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 Fri Dec 31 2010 at 19:45:26 +, David Laight wrote: > 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. That's good advise to someone who is configuring an nfs server. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
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