Re: FreeBSD Kernel Quality?
You have to Send them an email. Just the link to the right of the project title. It will open an email with some questions to answer and send to them. Ben On Thu, 2006-04-06 at 16:34 -0700, Avleen Vig wrote: > On Thu, Apr 06, 2006 at 09:30:28AM -0700, Sam Leffler wrote: > > OTOH we've done nothing with user application code and based on the > > work I've seen done by netbsd there's plenty of stuff to be fixed > > there. So if you want to help out get an account and start feeding > > back fixes for the user code. > > How does one "get an account" ?? :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Thu, Apr 06, 2006 at 12:37:03PM -0700, Darren Pilgrim wrote: > >Access control is done via permissions of files in /dev. If I have > >proper permissions to a device file, I can mount it at a directory > >I own. If I don't have proper permissions to a device file, I cannot > >mount it at all. This has nothing to do with fstab. > > But it does. GNOME/KDE provides a means of mounting devices by users that > would otherwise require a suid mount program. If GNOME/KDE allowed this > functionality to be used directly with devices, rather than through fstab, > then without writing an parallel access control system into GNOME/KDE, > there would be nothing stopping a user from exploiting it to mount system > volumes. So GNOME/KDE are already using suid binaries for mounting? I do not see how else users would be able to mount arbitrary volumes. People said they do not like suid binaries. This is exactly what could be avoided with just using vfs.usermount to control mounting from within KDE/GNOME. Proper access control system is already there with vfs.usermount and /dev permissions. No need to write a parallel system. There is one already - in fact, it looks like GNOME/KDE are already duplicating functionality. I don't really see a reason to have suid binaries at all if you have something like vfs.usermount. It is much better than how Linux does it (/bin/mount is setuid in Linux). > >That's true - but you could provide sane default options, and make > >them changable via the gui. If there are quotas on a file system, > >or anything else you don't want the user to mess with, well, don't > >give the user access to the device node in /dev. > > That's the point exactly, we don't want users having direct access to the > device nodes. fstab allows that by providing a means of referencing device > nodes without specifying them to the mount command and also allows devices > to be marked with the filesystem and mount options desired. If GNOME/KDE > had code to parallel fstab, then the GNOME/KDE developers have to keep up > with changes to available filesystems and mount options for every supported > OS out there. That's a lot of work just to parallel and already adequate > system. It's true that changing the way GNOME and KDE operate involves lots of porting work. But that's what the FreeBSD/KDE and FreeBSD/Gnome projects are there for, aren't they? I bet they've made much larger adjustments than changing they way mounts are handled (but I don't know and I'm just bluntly guessing here). And the current system is not adequate: Consider massive multi-user installations, like university computer pools. You don't want to list every student in fstab just so they can mount a CD or a USB stick. I do not administrate an environment on that scale, but I know people who do and they told me they find it easier to do administrate large pools with Linux, because it has a user mount option for fstab. -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel Quality?
On Thu, Apr 06, 2006 at 09:30:28AM -0700, Sam Leffler wrote: > OTOH we've done nothing with user application code and based on the > work I've seen done by netbsd there's plenty of stuff to be fixed > there. So if you want to help out get an account and start feeding > back fixes for the user code. How does one "get an account" ?? :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel Quality?
Robert Watson wrote: On Wed, 5 Apr 2006, Benjamin D Adams wrote: I came across the fallowing website: http://scan.coverity.com/ Looks like they check open source projects for source quality. They Have the fallowing listed: The FreeBSD Foundation has negotiated a license to use the Coverity Prevent software as part of the FreeBSD.org cluster, so we have our own Prevent install. We do nightly runs on two branches and at least five hardware architectures, providing all FreeBSD developers with accounts on the Coverity bug database. This allows tracking long-term bug trends, immediate feedback on newly introduced bugs, etc. I'll actually be visiting Coverity on Wednesday to talk about expanding our use of their software. There's news blurb about the Coverity license on the FreeBSD Foundation web page, and we'll be cutting a press release in the near future (we have a draft, but it seems to have stalled, so hopefully my Coverity visit will kick it off again). Note that our private runs use some freebsd-specific models that eliminate many false positives in the analysis runs. This means, for the kernel at least, that the results may be misleading. We also have some issues that inflate the reportage somewhat and we're working with Coverity to resolve them. OTOH we've done nothing with user application code and based on the work I've seen done by netbsd there's plenty of stuff to be fixed there. So if you want to help out get an account and start feeding back fixes for the user code. Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setuid scripts wrapper (RFC, proposal)
> You should be able to get around this by opening the script > first, using fstatfs() and fstat() and passing the script as /dev/fd/N to > the interpreter. Great idea. Thank you very much. > What I was actually referring to was your use of argv[1], argv[2], argv[3] > and argv[4] without checking argc or otherwise validating them. Oops, I did it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setuid scripts wrapper (RFC, proposal)
On Thu, 2006-Apr-06 14:49:25 +0400, Sply Splyeff wrote: >> The biggest problem is its failure to check the sanity of the input >> parameters - that a particular argument actually exists before >> referencing it. > >Do you mean that evil Bob can substitue Alice's script between stat() and >execve() calls? >Yes, I've missed this point. Actually Bob can replace the script anytime between the initial statfs() call in your script and the interpreter opening the script sometime after the execve() call. You should be able to get around this by opening the script first, using fstatfs() and fstat() and passing the script as /dev/fd/N to the interpreter. What I was actually referring to was your use of argv[1], argv[2], argv[3] and argv[4] without checking argc or otherwise validating them. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: odd behavior with geom - gmirror - read/write simultaneously
I made a similar test with FreeBSD 4.11, and the results are OK. This problem didnt happen. On 4/6/06, Thiago Damas <[EMAIL PROTECTED]> wrote: > Hi, > same problem: > * in shell(1): > # dd if=/dev/zero of=/var/tmp/test bs=4m > * after some time (=~ 20seconds), in shell(2) > # dd if=/var/tmp/test bs=4m of=/dev/null > > gstat shows no writes again, only reads; hitting ^C in shell(1), it > hangs until the dd in shell(2) finishes. > > Using diferents files (after rebooting the machine to prevent some cache): > > > In: > same problem: > * in shell(1): > # dd if=/dev/zero of=/var/tmp/test bs=4m > * after some time (=~ 20seconds), in shell(2) > # dd if=/var/tmp/test bs=4m of=/dev/null > > gstat shows no writes again, only reads; hitting ^C in shell(1), it > hangs until the dd in shell(2) finishes. > > Using diferents files (after rebooting the machine to prevent some > cache), I found the inverse situation: > * in shell(1): > # dd if=/dev/zero of=/var/tmp/test2 bs=4m > * in shell(2): > # dd if=/var/tmp/test of=/dev/null bs=4m > > gstat shows the following: > # gstat > dT: 0.501 flag_I 50us sizeof 240 i -1 > L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name >11357 0 00.0357 45737 14.2 99.7| ad0 >11357 0 00.0357 45737 14.3 99.7| ad0s1 > 0 0 0 00.0 0 00.00.0| ad2 > 0 0 0 00.0 0 00.00.0| ad3 > 0 0 0 00.0 0 00.00.0| ad0s1a > 0 0 0 00.0 0 00.00.0| ad0s1b > 0 0 0 00.0 0 00.00.0| ad0s1c > 0 0 0 00.0 0 00.00.0| ad0s1d > 0 0 0 00.0 0 00.00.0| ad0s1e >11357 0 00.0357 45737 15.1 99.7| ad0s1f > 0 0 0 00.0 0 00.00.0| ad2s1 > 0 0 0 00.0 0 00.00.0| mirror/home0 > 0 0 0 00.0 0 00.00.0| ad3s1 > 0 0 0 00.0 0 00.00.0| mirror/home0s1 > 0 0 0 00.0 0 00.00.0| mirror/home0s1c > > Hitting ^C in shell(2), it hangs until I cancel the dd of shell(1), > and shows the following: > # dd if=/var/tmp/test of=/dev/null bs=4m > ^C0+0 records in > 0+0 records out > 0 bytes transferred in 23.318283 secs (0 bytes/sec) > > In: > > When I try your test on my mirror gstat shows read and write activity, > > but the reading dd quits very soon, because reading appears to be faster > > than writing. > try waiting a little more before execute the dd command. > > > After those tests, the problem isnt relationated with GEOM, I think. > What can I do now? > > > > > > Did you try the parallel dd commands on another partition which is not > > gmirror'd? For example: > > > > dd if=/dev/ad0 of=/var/tmp/test.data bs=4m > > dd if=/var/tmp/test.data bs=4m of=/dev/null > > > > So you can be sure that it is a gmirror issue. > > > > When I try your test on my mirror gstat shows read and write activity, > > but the reading dd quits very soon, because reading appears to be faster > > than writing. > > > > I would suggest that you write to one file and read from another file > > when you do the parallel test. > > > > Just a hint: for the write test you should better use /dev/zero instead > > of /dev/ad0 - ``dd if=/dev/zero of=/home/test.data bs=4m'' for obvious > > reasons. > > > > -- > > Vasil Dimov > > [EMAIL PROTECTED] > > > > Testing can show the presence of bugs, but not their absence. > > -- Edsger W. Dijkstra > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
In <[EMAIL PROTECTED]>, Jilles Tjoelker <[EMAIL PROTECTED]> typed: > Consider chown(8)ing the mount points to the current user on login (and > root on logout) (using DisplayManager._0.startup and > DisplayManager._0.reset or similar). /etc/fbtab is designed for exactly this problem. That's what I use. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: odd behavior with geom - gmirror - read/write simultaneously
Hi, same problem: * in shell(1): # dd if=/dev/zero of=/var/tmp/test bs=4m * after some time (=~ 20seconds), in shell(2) # dd if=/var/tmp/test bs=4m of=/dev/null gstat shows no writes again, only reads; hitting ^C in shell(1), it hangs until the dd in shell(2) finishes. Using diferents files (after rebooting the machine to prevent some cache): In: same problem: * in shell(1): # dd if=/dev/zero of=/var/tmp/test bs=4m * after some time (=~ 20seconds), in shell(2) # dd if=/var/tmp/test bs=4m of=/dev/null gstat shows no writes again, only reads; hitting ^C in shell(1), it hangs until the dd in shell(2) finishes. Using diferents files (after rebooting the machine to prevent some cache), I found the inverse situation: * in shell(1): # dd if=/dev/zero of=/var/tmp/test2 bs=4m * in shell(2): # dd if=/var/tmp/test of=/dev/null bs=4m gstat shows the following: # gstat dT: 0.501 flag_I 50us sizeof 240 i -1 L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 11357 0 00.0357 45737 14.2 99.7| ad0 11357 0 00.0357 45737 14.3 99.7| ad0s1 0 0 0 00.0 0 00.00.0| ad2 0 0 0 00.0 0 00.00.0| ad3 0 0 0 00.0 0 00.00.0| ad0s1a 0 0 0 00.0 0 00.00.0| ad0s1b 0 0 0 00.0 0 00.00.0| ad0s1c 0 0 0 00.0 0 00.00.0| ad0s1d 0 0 0 00.0 0 00.00.0| ad0s1e 11357 0 00.0357 45737 15.1 99.7| ad0s1f 0 0 0 00.0 0 00.00.0| ad2s1 0 0 0 00.0 0 00.00.0| mirror/home0 0 0 0 00.0 0 00.00.0| ad3s1 0 0 0 00.0 0 00.00.0| mirror/home0s1 0 0 0 00.0 0 00.00.0| mirror/home0s1c Hitting ^C in shell(2), it hangs until I cancel the dd of shell(1), and shows the following: # dd if=/var/tmp/test of=/dev/null bs=4m ^C0+0 records in 0+0 records out 0 bytes transferred in 23.318283 secs (0 bytes/sec) In: > When I try your test on my mirror gstat shows read and write activity, > but the reading dd quits very soon, because reading appears to be faster > than writing. try waiting a little more before execute the dd command. After those tests, the problem isnt relationated with GEOM, I think. What can I do now? > > Did you try the parallel dd commands on another partition which is not > gmirror'd? For example: > > dd if=/dev/ad0 of=/var/tmp/test.data bs=4m > dd if=/var/tmp/test.data bs=4m of=/dev/null > > So you can be sure that it is a gmirror issue. > > When I try your test on my mirror gstat shows read and write activity, > but the reading dd quits very soon, because reading appears to be faster > than writing. > > I would suggest that you write to one file and read from another file > when you do the parallel test. > > Just a hint: for the write test you should better use /dev/zero instead > of /dev/ad0 - ``dd if=/dev/zero of=/home/test.data bs=4m'' for obvious > reasons. > > -- > Vasil Dimov > [EMAIL PROTECTED] > > Testing can show the presence of bugs, but not their absence. > -- Edsger W. Dijkstra ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Adding a ``user'' mount option
On Tue, Apr 04, 2006 at 01:45:47PM +0200, Stefan Sperling wrote: > Why do GNOME/KDE rely on /etc/fstab on FreeBSD? > What are admins supposed to do on systems with more than, say, a hundred > users. Having to add a line to /etc/fstab for every user is of course > scriptable, but that does not make it less insane. > As far as I got it, the current design boils down to the user creating > a mount point, and then mounting the media "manually", e.g. > mount /dev/cd0 ~/cdrom. Granted the admin has set vfs.usermount to 1, > of course. I don't really think that user mount has been designed > with /etc/fstab in mind. Consider chown(8)ing the mount points to the current user on login (and root on logout) (using DisplayManager._0.startup and DisplayManager._0.reset or similar). I do this on a few multiuser boxes (at most 5 users per box though) and all users can use the same /etc/fstab lines. The mount will only work for the locally logged in user, which may be considered a bug or a feature ;-) -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel Quality?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.coverity.com%2Fmain.html *cough* :) Fredrik Lindberg wrote: Benjamin D Adams wrote: Anyone know what version they are testing this on? Some may want to login and look at the problems they found. You should search the cvs-src mailinglist for the following lines Found with: Coverity Prevent(tm) Found by: Coverity Analysis tool[1]. and other variants :) Fredrik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setuid scripts wrapper (RFC, proposal)
> The biggest problem is its failure to check the sanity of the input > parameters - that a particular argument actually exists before > referencing it. Do you mean that evil Bob can substitue Alice's script between stat() and execve() calls? Yes, I've missed this point. We can use realpath and check if all nodes are writable only by file owner or by root. Yes, that's a big limitation, but in most common tasks it would be acceptable. And it saves from race conditions, am I right? And there are another ways but more slowly or complex - own sub-wrapper for each interpreter with passes script as file descriptor as you wrote at beginning; hardlink or copy files to safe directory; fork child and ptrace him for watching if the files it opens are really the same. Too confusing. But if the first way is ok, maybe it'sbetter to stay on it. > Other issues I noticed: > - strncpy() is virtually always the wrong function. You already do > validation so you could just use strcpy() ok. i've replace to memcpy as len is already known > - strncpy(penvd + penvsz, "=", 1); could be penvd[penvsz] = '='; sure, it was done only for hold in one style all string operations > - No error if number of environment variables too great. fixed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setuid scripts wrapper (RFC, proposal)
On Thu, 2006-Apr-06 00:29:27 +0400, Sply Splyeff wrote: >There are some security problems with kernel-level script >setuid execution which discourage from using it. The biggest problem is a race condition between the kernel setting up the set[gu]id() environment and opening the script to find the interpreter and the interpreter opening the script to execute it. This can only be fixed withing the kernel (by passing the script to the interpreter as a pre-opened FD). >Is it strong enough? Maybe there is any slippery ground >left? The biggest problem is its failure to check the sanity of the input parameters - that a particular argument actually exists before referencing it. Other issues I noticed: - strncpy() is virtually always the wrong function. You already do validation so you could just use strcpy() - strncpy(penvd + penvsz, "=", 1); could be penvd[penvsz] = '='; - No error if number of environment variables too great. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Kris Kennaway wrote: > I get this panic with mount_unionfs -b: We cannot get the same kernel panic error. Please give us a how-to-repeat-the-same-problem in simple way. > kdb_backtrace(ebf369e8,c056b59a,c06c905a,c06e297e,c72d7000) at > kdb_backtrace+0x29 > vfs_badlock(c06c905a,c06e297e,c72d7000) at vfs_badlock+0x11 > assert_vop_locked(c72d7000,c06e297e,c72d7000,c06e297e) at > assert_vop_locked+0x4a > VOP_OPEN_APV(c0710da0,ebf36a28) at VOP_OPEN_APV+0x8e > union_open(ebf36a78,ebf36b20,c74e0930,ebf36ae4,c04f884b) at union_open+0xe2 > VOP_OPEN_APV(c06f83a0,ebf36a78) at VOP_OPEN_APV+0x9b > exec_check_permissions(ebf36b90,9,1,0,0) at exec_check_permissions+0xeb > do_execve(c6658bd0,ebf36c60,0,ebf36c60,c6658bd0) at do_execve+0x18a > kern_execve(c6658bd0,ebf36c60,0) at kern_execve+0x7c > execve(c6658bd0,ebf36d04,c6bb5d38,c,c6658bd0) at execve+0x2f > syscall(3b,3b,3b,bfbfe90c,0) at syscall+0x27e > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (59, FreeBSD ELF32, execve), eip = 0x280d3dfb, esp = 0xbfbfe35c, > ebp = 0xbfbfe808 --- > VOP_OPEN: 0xc72d7000 is not locked but should be > > Kris -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel Quality?
On Wed, 5 Apr 2006, Benjamin D Adams wrote: I came across the fallowing website: http://scan.coverity.com/ Looks like they check open source projects for source quality. They Have the fallowing listed: The FreeBSD Foundation has negotiated a license to use the Coverity Prevent software as part of the FreeBSD.org cluster, so we have our own Prevent install. We do nightly runs on two branches and at least five hardware architectures, providing all FreeBSD developers with accounts on the Coverity bug database. This allows tracking long-term bug trends, immediate feedback on newly introduced bugs, etc. I'll actually be visiting Coverity on Wednesday to talk about expanding our use of their software. There's news blurb about the Coverity license on the FreeBSD Foundation web page, and we'll be cutting a press release in the near future (we have a draft, but it seems to have stalled, so hopefully my Coverity visit will kick it off again). Robert N M Watson Project | Current # | Original # | Lines of Code | Defects / Defects Defects KLOC ++ FreeBSD 632 6351,582,166 0.399 NetBSD 2384 32305,087,378 0.469 Anyone know what version they are testing this on? Some may want to login and look at the problems they found. I filled out a Registration email to find out more. Anyone already registered and can say more about the code they are testing? -- --- Benjamin D Adams http://www.FreeBSDWorld.NET ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel Quality?
Benjamin D Adams wrote: Anyone know what version they are testing this on? Some may want to login and look at the problems they found. You should search the cvs-src mailinglist for the following lines Found with: Coverity Prevent(tm) Found by: Coverity Analysis tool[1]. and other variants :) Fredrik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
