Re: Fdescfs updates--coming to a devfs near you!
On Tue, 19 Sep 2000, Bruce Evans wrote: On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote: I recently ran into revelant problem with /dev/stdout, while working on some software under linux that expected /dev/stdout as an argument instead of using stdout. Using the device file breaks, if the process is suid to a non-root user. This is because it cannot open /dev/stdout, which is owned by your UID and not the EUID of the process to which the device was passed. My solution was to add the "-" hack and use the existing open descriptor. Um, open on fdesc devices doesn't check either uid. It just checks the access mode. Perhaps the software expected /dev/stdout to for read-write like a tty would be. Then opening /dev/stdout would fail for normal shell output redirection which only opens for writing. No, it wasn't a RW/W issue. I dug a little deeper. It looks like the BSD implmentation of /dev/stdout is smarter than the linux version. Linux's is a symlink into /proc and the device ownership is determined by the UID of the invoking user. I guess I wouldn't have have had a problem under BSD. no suprise here. Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, 14 Sep 2000, Ben Smithurst wrote:
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
You think adding a hack to every program to support "-" to mean
stdout/stdin is better? It seems to be that saying "/dev/stdin" when
you mean stdin is better than saying "-" and hoping the application
handles that correctly. Of course many programs will read stdin by
default, and write stdout by default, but that doesn't help when you
want to read more than one file, one of which is stdin.
If anything I would propose we ditch it...
And break loads of scripts at the same time?
I recently ran into revelant problem with /dev/stdout, while
working on some software under linux that expected /dev/stdout as an
argument instead of using stdout.
Using the device file breaks, if the process is suid to a non-root
user. This is because it cannot open /dev/stdout, which is owned by your
UID and not the EUID of the process to which the device was passed. My
solution was to add the "-" hack and use the existing open descriptor.
Still, I don't think /dev/stdout and friends are such bad things
that they should be abandoned. They are present in other OS's and it does
help avoid making named pipes and the such when you need the behavior the
special devices provide. I think it would simple create minor poratability
issues for third party software.
Adrian
--
[ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: About /usr/mdec/cdboot
On Sun, 31 Jan 1999, Tomoyoshi ASANO wrote: When CD booting, some error messages is displayed. And I tested other machines supported atapi-cdrom booting. (In /usr/sys/i386/boot/cdboot/boot.c) Your BIOS int 0x13 extensions seem to be disabled. It's impossible to boot a CD-ROM without them. (BIOS int 0x13 fn 0x4b01 yielded error ?) I'm sorry I don't know 0x13 extensions. Is /usr/mdec/cdrom supported atapi-cdrom booting ? Check that your BIOS is enabled. It's talking about hooking into the BIOS disk IO routines such that they can access the SCSI device. If you can boot from a hard disk on this controller, then you should be able to boot from a CD-ROM on the same controller, if it supports CD-ROM booting at all. Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
