Amit <[email protected]> writes: > Andrei POPESCU <andreimpopescu <at> gmail.com> writes: > >> >> On Lu, 26 nov 12, 22:33:51, Amit wrote: >> > >> > Yes, I basically want to avoid even the root user (or process with root >> > privileges) to able to access this. So the kernel has to be replaced in >> > order to disable the "write protect" on that USB port. >> > >> > It is more of a guarantee that there can be no accidental write on that >> > device plugged in to that port. >> >> There is no guarantee besides removing the device from the port[1]. Even >> if you were to remove write support from the usb-storage module (or >> whatever part of the kernel is responsible for that), one can still >> accidentally boot another kernel. >> >> [1] and if you're worried about data corruption this is still not enough >> >> What exactly are you trying to achieve? Maybe we can suggest better >> ways. >> >> Kind regards, >> Andrei > > Thanks for the response. > > This is more of a personal use case. That is, I end up analyzing hard > drives using the regular Linux tools (hdparm, datadump, etc.) and my own > custom C programs that simply open /dev/sd[x] and read and analyze data. > > Now, for example, there have been cases where I accidentaly (as root), > do a dd and overwrite a portion of the drive I was analyzing/reading from. > > So by modifying the kernel to disable writes to this port, I can give > myself a personal guarantee that no matter what I or the programs I have > written do, no writes will get through. > > I am aware I can image these drives by using dd and then analyzing the > dd image. However, I would like to avoid this if possible. The main > reason is because my current system has very limited hard drive space > and is quite slow (500MHz G4 PPC). > > I hope this use case makes sense. >
There is a blockdev command with a --setro option in the util-linux package. You can modify your udev rules to run this command when the device is plugged in. -- regards, kushal -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
