On Friday 18 July 2003 09:39, Omen Wild wrote: > Quoting Seth Arnold <sarnoldat_private> on Wed, Jul 16 21:51: > > Nah, the usermodehelper thing can't block for reading response from > > userspace. Fire and forget. It probably isn't what you want. > > [ snip ] > > > But please give the user daemon option a shot before resorting to > > this. > > I have to admit I'm confused over these two statements. Any user > daemon would have to block the kernel from finishing the open operation > until it could decided if the file is intact. Or are you suggesting a > much more complicated scheme would be required (a queue with an upcall > when the daemon finishes)? Ummmm maybe not... you do have to modify a fileid (since the file is already being opened anyway). Open the file as usual, then before returning to the application pass the fileid to the daemon as an already open fileid. ((I admit - I haven't done this myself)) This would allow the daemon to implement a queue of fileids to process. > Has anyone compiled a list of arguments for/against implementing things > in user space? I want to do the right thing, but I can't convince > myself that doing it in the kernel is wrong. The normal reasons for not doing things in the kernel are: 1. ease of debugging 2. ease of update 3. less restrictive stack 4. more flexable runtime (easier buffer management) 5. a bug won't crash your system. 6. Long data intensive operations can hang your system. 7. Use of floating registers is possible (not applicable to this case though) 8. Less invasive of the kernel. 9. Less kernel bloat. > > And, against my better judgement, I'll mention that you can use > > kernel_read() to read files from within the kernel. > > Thanks for the pointer, that did the trick! > > Now, how about opening a file from within the kernel? I have a config > file to read. I saw a message in the archives about this and someone > recommended a /proc interface, but I need to be able to verify init as > it is read off the disk, before any part of user space is running. I think you are pushing too far.... How do you know the configuration file hasn't been messed with? What are you planning to do about "init=/bin/sh" boot situations where the system needs repair? (my personal favorite is "init=/sbin/fsck.xxx") What are you going to do when the filesystem is damaged? The normal recovery is to do a fsck on a RO filesystem, then remount. What if the configuration file is altered/damaged by the fsck after you read it? What if you can't read it? _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jul 18 2003 - 09:07:24 PDT