Re: writing much slower than reading...
Jonathan Lemon scribbled this message on Nov 6: > Try doing `iostat 1' while doing the transfers. This is what I see here: > > tty da0 da1 da2 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > TEST A:0.00 0 0.00 64.00 119 7.47 0.00 0 0.00 0 0 3 0 97 > TEST B:0.00 0 0.00 64.00 419 26.18 0.00 0 0.00 0 0 1 0 99 > TEST C:0.00 0 0.00 64.00 95 5.94 64.00 95 5.94 0 0 1 0 99 > TEST D: 63.84 338 21.05 64.00 343 21.41 0.00 0 0.00 0 0 26 2 72 > > TEST A: (writing) dd if=/dev/zero of=/dev/rda1 bs=1m count=400 > TEST B: (reading) dd if=/dev/rda1 of=/dev/zero bs=1m count=400 > TEST C: (read & write)dd if=/dev/rda1 of=/dev/rda2 bs=1m count=400 > TEST D: (read raw & write fs) dd if=/dev/rda1 of=trash bs=1m count=400 tty wd0 cpu tin tout KB/t tps MB/s us ni sy in id TEST A: 113.50 182 20.19 0 0 27 1 72 TEST B: 113.63 202 22.41 0 0 2 2 96 TEST C: 114.07 174 19.40 0 0 2 1 97 TEST D: 81.92 224 17.89 0 0 48 3 48 since I only have on drive, TEST C was dd of=/dev/rwd0s1g if=/dev/rwd0s1g bs=1m count=400, and TEST D was writing to the same drive that I was reading from, no softupdates enabled... and I was doing all testing on /dev/rwd0s1g so I could write... > System is a Dell Poweredge 4300 PIII/600, all disks are Seagate ST39103LC. k6-2/250 (100mhz system bus), IBM-DPTA-372730 > Disk da0 (where the trash file is written) has softupdates enabled. This > is on a week old -current. > > I'm suprised by the last line. Writing to the filesystem is faster > than writing to the raw device? I must be missing something here. I'm surprised at the last two lines... I didn't think that I would be able to push/pull that much data at once, but considering that it didn't have to seek far it isn't that surprising... h... could this be a deficency in the IDE driver?? sounds like I need to test the new ata driver and see if it performs better... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
> Is this a real problem, or is it a "well don't protect suid > executables that way" problem? The permissions used in Linux's > /proc seem to be more conservative and seem to prevent this. Yes. This is a real problem. One of the security team has had patches since before FreeBSD CON. There are other related problems. The easy way out is to remove file completely, but there were some objections to doing that, so things haven't been committed. : Err... I don't see the problem. The permissions of the hardlink will : be different, so the user might be able to see the "code", but won't : be able to run the suid (because the hardlink won't have the suid : bit set). There are ways that the user can see the code to execute it, but not read it normally. procfs breaches this inability to read the file. Also, there are many related problems which make a proper fix for this that is more complicated than removing /proc/xxx/file nearly impossible. "Proper" here means "A fix which will prevent the disclosure of a file to unauthorized people which would normally not be able to read the file." I'm convinced that it would be hard to codify all the security checks needed to access the file originally into a single number which would allow people that could read the original file to read /proc/xxx/file and disallow people who couldn't read the file to also be disallowed from reading /proc/xxx/file. The example that convinced me of this is /a/b/foo. /a mode 750 user joe group joeys /a/bmode 750 user bob group briggs /a/b/foomode 555 user tim group timbo What should the owner/group of /proc/xxx/file be? One option would be 550 user tim, group timbo. However, this allows users that are in group timbo, but aren't in group briggs AND joeys to read the file. Another option would be 500 user tim group timbo, but this then disallows people that are in groups timbo, brigs and joeys, who aren't user tim from reading the file (as well as others who could read /a/b/foo). There is not one number for the example (or other more complicated ones that I could construct) that works exactly the same as the filesystem does. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: exec() security enhancement
On Sun, Nov 07, 1999 at 03:53:50AM +0900, Daniel C. Sobral wrote:
> [and, as you said, the same goes for nosuid -- and for nodev too]
>
> This doesn't enhance security. It enhances auditability. I like
> this. Add a syslog, and a sysctl to turn it on or off. It seems
> straight-forward and light-weight. Send the patches. :-)
I quickly wrote the code to do this this evening. Its almost
ready to be contributed.
What should the sysctl ndoes be named? These really implement
similar functionality to net.inet.{tcp|udp}.log_in_vain, but
obviously don't belong under net.
What about something like "kern.audit.*"?
There are probably several other areas that we could increase
the kernel's verbosity, and put the sysctls under there.
Comments? Suggestions?
- Steve
--
C. Stephen Gunn URL: http://www.waterspout.com/
WaterSpout Communications, Inc.Email: [EMAIL PROTECTED]
427 North 6th Street Phone: +1 765.742.6628
Lafayette, IN 47901 Fax: +1 765.742.0646
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
In message <[EMAIL PROTECTED]> Brian Fundakowski Feldman writes: : It sounds to me that what you really want are the semantics of a : symbolic link and not the semantics of a hard link. Is it just me, : or does it seem as if the pathname of the executable being stored as : a virtual symlink in procfs as "file" would solve these security : problems? If you can get to the full path to the original file, this is likely the answer. I don't know if that information is easily available or not. My memory of the proc structure is that it has a vnode to the executable, which is easy to produce as an alias in /proc/xxx/file, but much harder to get the original path to. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
Brian Fundakowski Feldman wrote: > > It sounds to me that what you really want are the semantics of a > symbolic link and not the semantics of a hard link. Is it just me, > or does it seem as if the pathname of the executable being stored as > a virtual symlink in procfs as "file" would solve these security > problems? M... I like that... -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
