Re: Fixing documented bug in env(1)

2001-06-04 Thread Mark Valentine
From: [EMAIL PROTECTED] (Mike Meyer) Date: Mon 4 Jun, 2001 Subject: Re: Fixing documented bug in env(1) #!/usr/bin/env foobar will work just fine. At the mercy of the user's path... Cheers, Mark. -- Mark Valentine, Thuvia Labs [EMAIL PROTECTED]

Re: Fixing documented bug in env(1)

2001-06-04 Thread Mike Meyer
Mark Valentine [EMAIL PROTECTED] types: From: [EMAIL PROTECTED] (Mike Meyer) Date: Mon 4 Jun, 2001 Subject: Re: Fixing documented bug in env(1) #!/usr/bin/env foobar will work just fine. At the mercy of the user's path... If you're really worried about that, do #!/usr/bin/env

cyclades Cyclom-8Ys card with newer firmware

2001-06-04 Thread Falco Krepel
Hello Andrew, I want to use the Cyclom-8Ys card for a console server (with FreeBSD 5.0). But the driver doesn't work. First I get the error No ports found. After debugging I found the problem. You check in cy.c in the function cy_units() the firmware version. If the firmware is between

RE: Patch to fix code that kills procs when swap runs out (stabl

2001-06-04 Thread John Baldwin
On 03-Jun-01 Matt Dillon wrote: Alfred, I'm cc'ing you. If you have some time, could you check the vmspace_swap_count() routine? What do I need to mutex it for -current? For -stable I don't think there's an issue since VM objects are not instantiated/destroyed by

speeding up /etc/security

2001-06-04 Thread Rich Morin
/etc/security takes a number of hours to run on my system. The problem is that I have some very large mounted file systems and the code to look for setuid files wants to walk through them all. I recoded the check in Perl, but it ran at about the same speed. I have considered reworking the code

Re: speeding up /etc/security

2001-06-04 Thread Matthew Jacob
That's an interesting question. A couple of ideas: a) I wonder of RWatson's ACL stuff could help here? b) This problem cries for a DMAPI type solution- you could have a daemon that monitors all creats/chmods and retains knowledge of the filenames for all SUID/SGID creats/chmods- this way

Re: speeding up /etc/security

2001-06-04 Thread Wilko Bulte
On Mon, Jun 04, 2001 at 12:07:19PM -0700, Matthew Jacob wrote: Does /etc/security take filesystem mounted with: nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. Note: this option is worthless if a public available suid or sgid wrapper

Re: speeding up /etc/security

2001-06-04 Thread Gersh
What about something like what process accounting does? It would be trivial to update a file (say /var/db/setxid) whenever certian chmod / fchmod actions are taken. If it only happened when chmod/fchmod actions happened that effected setxid stauts it should not impact performence to much either

Re: speeding up /etc/security

2001-06-04 Thread Matthew Jacob
Let me turn it around and say that process accounting should be only one of a set of actions that can be emitted from the kernel and recorded somewhere. On Mon, 4 Jun 2001, Gersh wrote: What about something like what process accounting does? It would be trivial to update a file (say

pipe implementation questions

2001-06-04 Thread Jaromír Dolecek
Hi folks, I'm working on a port of FreeBSD pipe implementation to NetBSD. So far, the results are pretty owesame, the new pipes are significantly faster than the old socketpair-based ones. Good work! However, I found couple of things I don't quite understand and would like to clarify if this is

Re: speeding up /etc/security

2001-06-04 Thread Brian Somers
As you suspect, mounting nosuid makes /etc/security skip the suid checks... good for giving the security-unconscious a reason to fix their system :) I was alway quite impressed with this :) On Mon, Jun 04, 2001 at 12:07:19PM -0700, Matthew Jacob wrote: Does /etc/security take filesystem

Re: speeding up /etc/security

2001-06-04 Thread Rich Morin
At 10:48 PM +0100 6/4/01, Brian Somers wrote: As you suspect, mounting nosuid makes /etc/security skip the suid checks... good for giving the security-unconscious a reason to fix their system :) Works for me... -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm -

Re: speeding up /etc/security

2001-06-04 Thread Kevin Way
Does /etc/security take filesystem mounted with: nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. Note: this option is worthless if a public available suid or sgid wrapper like suidperl(1) is installed on your system.

Re: background_fsck rc.conf option

2001-06-04 Thread Andreas Dobloug; UiO; H98
--cut here-- Index: etc/rc === RCS file: /stl/src/FreeBSD/src/etc/rc,v retrieving revision 1.264 diff -u -r1.264 rc --- etc/rc 2001/05/13 20:43:30 1.264 +++ etc/rc 2001/05/21 00:19:25 @@ -184,9 +184,14 @@ case

Resource reservation idea

2001-06-04 Thread Jonathan Chen
Currently on FreeBSD, resources are either free, allocated or activated. As I understand it, they mean approximately the following: - Free: unused. - Allocated: Resource reserved for use by device X. - Activated: Resource actively used by device X. This leaves somewhat of a gap. What if

Re: Resource reservation idea

2001-06-04 Thread Mike Smith
Currently on FreeBSD, resources are either free, allocated or activated. As I understand it, they mean approximately the following: - Free: unused. - Allocated: Resource reserved for use by device X. - Activated: Resource actively used by device X. This leaves somewhat of a gap.

Re: speeding up /etc/security

2001-06-04 Thread Kevin Way
The answer there is 'sort of'. /etc/security checks all ufs partitions that aren't marked nosuid. if you're using anything other than UFS (e.g. MFS,ext2,whatever), it's not getting checked at all. i hate to followup to my own message, but in order for the SUID checks to be accurate, is

MFC'ing new md(4) functionality?

2001-06-04 Thread Dima Dorfman
Is there any reason not to MFC the new md(4) functionality (i.e., swap and vnode support)? With MFS and vn(4) gone in -current, I think that the sooner users can start moving to md(4) in -stable the less cries there will be come 5.0-RELEASE. Additionally, the porting effort is not that great.