Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Write protect access on USB port
107 views
Skip to first unread message
Amit
Nov 26, 2012, 3:10:01 PM11/26/12
to
Hello,
I would like to block write access by default to all drives plugged in
to my USB port (a specific USB port). This capability would probably be
at the kernel level to be effective.
Doing research on LWN.net, I noticed the following sentence by Corbet:
(http://lwn.net/Articles/428533/):
Enforcing read-only: The block layer has a mechanism by which a driver
can mark a specific device (or partition) as being read-only. This flag
may be set if the physical device is write-locked; it can also be set by
higher-level code (the DM or MD layers, for example) when the
administrator creates a read-only device.
Any idea on how this is done?
Thanks,
Amit
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/loom.2012112...@post.gmane.org
I would like to block write access by default to all drives plugged in
to my USB port (a specific USB port). This capability would probably be
at the kernel level to be effective.
Doing research on LWN.net, I noticed the following sentence by Corbet:
(http://lwn.net/Articles/428533/):
Enforcing read-only: The block layer has a mechanism by which a driver
can mark a specific device (or partition) as being read-only. This flag
may be set if the physical device is write-locked; it can also be set by
higher-level code (the DM or MD layers, for example) when the
administrator creates a read-only device.
Any idea on how this is done?
Thanks,
Amit
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/loom.2012112...@post.gmane.org
berenge...@neutralite.org
Nov 26, 2012, 3:20:01 PM11/26/12
to
You can enable read-only on partitions by using the "ro" flag in fstab.
By example:
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
#Entry for /dev/sda6 :
UUID=85bb1632-546f-460f-8cc7-5b15fd2c046b / ext4 noatime,errors=remount-ro 0 1
Here, / will be mounted with read-only if there were errors. I guess
that if you just remove the "errors=" it will be ro everytime.
Hope it helps.
Archive: http://lists.debian.org/73a3cbf7aa6af948...@neutralite.org
By example:
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
#Entry for /dev/sda6 :
UUID=85bb1632-546f-460f-8cc7-5b15fd2c046b / ext4 noatime,errors=remount-ro 0 1
Here, / will be mounted with read-only if there were errors. I guess
that if you just remove the "errors=" it will be ro everytime.
Hope it helps.
Amit
Nov 26, 2012, 4:30:03 PM11/26/12
to
<berenger.morel <at> neutralite.org> writes:
>
> You can enable read-only on partitions by using the "ro" flag in fstab.
>
> By example:
> # <file system> <mount point> <type> <options> <dump> <pass>
>
> proc /proc proc defaults 0 0
> #Entry for /dev/sda6 :
> UUID=85bb1632-546f-460f-8cc7-5b15fd2c046b / ext4 noatime,errors=remount-ro 0 1
>
> Here, / will be mounted with read-only if there were errors. I guess
> that if you just remove the "errors=" it will be ro everytime.
> Hope it helps.
>
Thanks for the reply. I was looking for block level write protect. That
>
> You can enable read-only on partitions by using the "ro" flag in fstab.
>
> By example:
> # <file system> <mount point> <type> <options> <dump> <pass>
>
> proc /proc proc defaults 0 0
> #Entry for /dev/sda6 :
> UUID=85bb1632-546f-460f-8cc7-5b15fd2c046b / ext4 noatime,errors=remount-ro 0 1
>
> Here, / will be mounted with read-only if there were errors. I guess
> that if you just remove the "errors=" it will be ro everytime.
> Hope it helps.
>
is, nobody can write a simple C program and use the open call and write
garbage to the device.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tom Furie
Nov 26, 2012, 4:40:01 PM11/26/12
to
On Mon, Nov 26, 2012 at 09:28:19PM +0000, Amit wrote:
>
> Thanks for the reply. I was looking for block level write protect. That
> is, nobody can write a simple C program and use the open call and write
> garbage to the device.
Tweak the udev rules to remove write permissions on the USB bus?
>
> Thanks for the reply. I was looking for block level write protect. That
> is, nobody can write a simple C program and use the open call and write
> garbage to the device.
Cheers,
Tom
--
Freedom is nothing else but the chance to do better.
-- Camus
berenge...@neutralite.org
Nov 26, 2012, 4:40:03 PM11/26/12
to
Le 26.11.2012 22:28, Amit a écrit :
> <berenger.morel <at> neutralite.org> writes:
>
>>
>> You can enable read-only on partitions by using the "ro" flag in
>> fstab.
>>
>> By example:
>> # <file system> <mount point> <type> <options> <dump>
>> <pass>
>>
>> proc /proc proc defaults 0 0
>> #Entry for /dev/sda6 :
>>
>> UUID=85bb1632-546f-460f-8cc7-5b15fd2c046b / ext4 noatime,errors=remount-ro 0 1
>>
>> Here, / will be mounted with read-only if there were errors. I guess
>> that if you just remove the "errors=" it will be ro everytime.
>> Hope it helps.
>>
>
> Thanks for the reply. I was looking for block level write protect.
> That
> is, nobody can write a simple C program and use the open call and
> write
> garbage to the device.
able to write on it, because the kernel is responsible of what will
happen. Low level open&close functions just call kernel's API, so if the
kernel refuse writings, I can not see a solution to write.
But I am not a kernel expert, I always prefer the standard C/C++
functions instead of OS's dependent low-level feature.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Amit
Nov 26, 2012, 4:50:02 PM11/26/12
to
<berenger.morel <at> neutralite.org> writes:
>
> If a partition is mounted as read-only, I think no software will be
> able to write on it, because the kernel is responsible of what will
> happen. Low level open&close functions just call kernel's API, so if the
> kernel refuse writings, I can not see a solution to write.
> But I am not a kernel expert, I always prefer the standard C/C++
> functions instead of OS's dependent low-level feature.
>
Hello,
>
> If a partition is mounted as read-only, I think no software will be
> able to write on it, because the kernel is responsible of what will
> happen. Low level open&close functions just call kernel's API, so if the
> kernel refuse writings, I can not see a solution to write.
> But I am not a kernel expert, I always prefer the standard C/C++
> functions instead of OS's dependent low-level feature.
>
Yes the above would work in most cases but in the case I am dealing
with, the filesystem is not mounted yet. For example, I plug in a USB
drive. Before it is mounted, there is a /dev/sd[x] node. I can open
this node and write anything I want, thereby corrupting the filesystem
on that device.
Thanks,
Amit
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrei POPESCU
Nov 26, 2012, 5:20:01 PM11/26/12
to
On Lu, 26 nov 12, 21:47:36, Amit wrote:
>
> Yes the above would work in most cases but in the case I am dealing
> with, the filesystem is not mounted yet. For example, I plug in a USB
> drive. Before it is mounted, there is a /dev/sd[x] node. I can open
> this node and write anything I want, thereby corrupting the filesystem
> on that device.
Not unless you are 'root' or member of group 'floppy':
>
> Yes the above would work in most cases but in the case I am dealing
> with, the filesystem is not mounted yet. For example, I plug in a USB
> drive. Before it is mounted, there is a /dev/sd[x] node. I can open
> this node and write anything I want, thereby corrupting the filesystem
> on that device.
$ ls -l /dev/sdb1
brw-rw---T 1 root floppy 8, 17 nov 27 00:14 /dev/sdb1
You could just tweak the relevant udev rule to create the device nodes
as root:root or root:disk (like hard drives), since root would be able
to circumvent any protection and 'disk' is almost the same as 'root'.
Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
berenge...@neutralite.org
Nov 26, 2012, 5:20:02 PM11/26/12
to
> Yes the above would work in most cases but in the case I am dealing
> with, the filesystem is not mounted yet. For example, I plug in a USB
> drive. Before it is mounted, there is a /dev/sd[x] node. I can open
> this node and write anything I want, thereby corrupting the
> filesystem
> on that device.
>
> Thanks,
> Amit
I see what you mean.
> with, the filesystem is not mounted yet. For example, I plug in a USB
> drive. Before it is mounted, there is a /dev/sd[x] node. I can open
> this node and write anything I want, thereby corrupting the
> filesystem
> on that device.
>
> Thanks,
> Amit
But on my computer, when I do "$cat /dev/sda" I have "cat: sda:
Permission non accordée" which mean : access denied.
Only root can access stuff in /dev, so do you want to protect your usb
stuff against root?
If yes, I can do nothing for you, and I think you'll have to play with
kernel.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Amit
Nov 26, 2012, 5:40:02 PM11/26/12
to
Andrei POPESCU <andreimpopescu <at> gmail.com> writes:
>
> On Lu, 26 nov 12, 21:47:36, Amit wrote:
> >
> > Yes the above would work in most cases but in the case I am dealing
> > with, the filesystem is not mounted yet. For example, I plug in a USB
> > drive. Before it is mounted, there is a /dev/sd[x] node. I can open
> > this node and write anything I want, thereby corrupting the filesystem
> > on that device.
>
> Not unless you are 'root' or member of group 'floppy':
>
> $ ls -l /dev/sdb1
> brw-rw---T 1 root floppy 8, 17 nov 27 00:14 /dev/sdb1
>
> You could just tweak the relevant udev rule to create the device nodes
> as root:root or root:disk (like hard drives), since root would be able
> to circumvent any protection and 'disk' is almost the same as 'root'.
>
> Kind regards,
> Andrei
Thanks for the reply.
>
> On Lu, 26 nov 12, 21:47:36, Amit wrote:
> >
> > Yes the above would work in most cases but in the case I am dealing
> > with, the filesystem is not mounted yet. For example, I plug in a USB
> > drive. Before it is mounted, there is a /dev/sd[x] node. I can open
> > this node and write anything I want, thereby corrupting the filesystem
> > on that device.
>
> Not unless you are 'root' or member of group 'floppy':
>
> $ ls -l /dev/sdb1
> brw-rw---T 1 root floppy 8, 17 nov 27 00:14 /dev/sdb1
>
> You could just tweak the relevant udev rule to create the device nodes
> as root:root or root:disk (like hard drives), since root would be able
> to circumvent any protection and 'disk' is almost the same as 'root'.
>
> Kind regards,
> Andrei
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.
Andrei POPESCU
Nov 26, 2012, 6:40:01 PM11/26/12
to
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
>
> 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.
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.
Amit
Nov 26, 2012, 7:00:03 PM11/26/12
to
> 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.
> >
> > 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
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.
Kushal Kumaran
Nov 27, 2012, 12:50:02 AM11/27/12
to
package. You can modify your udev rules to run this command when the
device is plugged in.
--
regards,
kushal
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dom
Nov 27, 2012, 2:20:01 AM11/27/12
to
On 26/11/12 22:18, Andrei POPESCU wrote:
> On Lu, 26 nov 12, 21:47:36, Amit wrote:
>>
>> Yes the above would work in most cases but in the case I am dealing
>> with, the filesystem is not mounted yet. For example, I plug in a USB
>> drive. Before it is mounted, there is a /dev/sd[x] node. I can open
>> this node and write anything I want, thereby corrupting the filesystem
>> on that device.
>
> Not unless you are 'root' or member of group 'floppy':
>
> $ ls -l /dev/sdb1
> brw-rw---T 1 root floppy 8, 17 nov 27 00:14 /dev/sdb1
>
> You could just tweak the relevant udev rule to create the device nodes
> as root:root or root:disk (like hard drives), since root would be able
> to circumvent any protection and 'disk' is almost the same as 'root'.
I just tested a basic udev rule which sets read-only permissions on any
> On Lu, 26 nov 12, 21:47:36, Amit wrote:
>>
>> Yes the above would work in most cases but in the case I am dealing
>> with, the filesystem is not mounted yet. For example, I plug in a USB
>> drive. Before it is mounted, there is a /dev/sd[x] node. I can open
>> this node and write anything I want, thereby corrupting the filesystem
>> on that device.
>
> Not unless you are 'root' or member of group 'floppy':
>
> $ ls -l /dev/sdb1
> brw-rw---T 1 root floppy 8, 17 nov 27 00:14 /dev/sdb1
>
> You could just tweak the relevant udev rule to create the device nodes
> as root:root or root:disk (like hard drives), since root would be able
> to circumvent any protection and 'disk' is almost the same as 'root'.
usb disk when inserted. Obviously root would be able to change those
permissions, but I don't believe any command (other than chmod) would
override read-only for the device file.
dom@oz:~$ cat /etc/udev/rules.d/99-usb-ro.rules:
#Make USB storage devices read only
KERNEL=="sd*",ACTION=="add",ENV{ID_BUS}=="usb",MODE="0444"
dom@oz:~$#(plugs in usb storage device)
dom@oz:~$ ls -l /dev/sd*
brw-rw---T 1 root disk 8, 0 Nov 27 03:16 /dev/sda
brw-rw---T 1 root disk 8, 1 Nov 27 03:16 /dev/sda1
brw-rw---T 1 root disk 8, 2 Nov 27 03:16 /dev/sda2
br--r--r-T 1 root floppy 8, 16 Nov 27 07:12 /dev/sdb
br--r--r-T 1 root floppy 8, 17 Nov 27 07:12 /dev/sdb1
dom@oz:~$
The rule may need a bit of tweaking perhaps. I'm not a udev expert by a
long way.
--
Dom
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Amit
Nov 27, 2012, 2:50:01 PM11/27/12
to
Kushal Kumaran <kushal.kumaran+debian <at> gmail.com> writes:
>
> 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.
>
Thanks I did not know about this tool. I looked at it and it
>
> 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.
>
accomplishes the read-only set by calling the BLKROSET ioctl (this is
alos done by hdparm -r).
However, this still poses a problem. Check out the following case:
1. Plug in a USB drive with an ext4 filesystem.
2. Set the readonly flag using blockdev.
3. Compute the checksum on this block device.
4. Mount the ext4 filesytem and then unmount it without doing anything.
5. Compute the checksum on the block device (checksum does not match).
The ext4 filesystem still updates the journal on the device and changes
the whole checksum.
Thanks,
Amit
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pascal Hambourg
Nov 27, 2012, 3:20:03 PM11/27/12
to
Hello,
Dom a écrit :
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50B51B95...@plouf.fr.eu.org
Dom a écrit :
>
> I just tested a basic udev rule which sets read-only permissions on any
> usb disk when inserted. [...]
> I just tested a basic udev rule which sets read-only permissions on any
>
> #Make USB storage devices read only
> KERNEL=="sd*",ACTION=="add",ENV{ID_BUS}=="usb",MODE="0444"
This won't work, root ignores file permissions.
> #Make USB storage devices read only
> KERNEL=="sd*",ACTION=="add",ENV{ID_BUS}=="usb",MODE="0444"
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrei POPESCU
Nov 27, 2012, 4:40:01 PM11/27/12
to
On Lu, 26 nov 12, 23:51:32, Amit wrote:
>
> 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.
Ok, I understand now. In my opinion such safety nets are dangerous,
>
> 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.
because they tend to encourage carelessness (not implying that you are
careless though). This is also the reason I stopped using rm aliased to
'rm -i'.
How about using the /dev/disk/by-* links when doing such dangerous
operations?
Pascal Hambourg
Nov 27, 2012, 7:20:02 PM11/27/12
to
Amit a écrit :
an the partition block device is still read-write.
The read-only flag must be set on the disk and all its partitions. I
guess udev can do this.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50B55280...@plouf.fr.eu.org
>
> However, this still poses a problem. Check out the following case:
>
> 1. Plug in a USB drive with an ext4 filesystem.
> 2. Set the readonly flag using blockdev.
> 3. Compute the checksum on this block device.
> 4. Mount the ext4 filesytem and then unmount it without doing anything.
> 5. Compute the checksum on the block device (checksum does not match).
>
> The ext4 filesystem still updates the journal on the device and changes
> the whole checksum.
That's because the filesystem is on a partition, not on the whole disk,
> However, this still poses a problem. Check out the following case:
>
> 1. Plug in a USB drive with an ext4 filesystem.
> 2. Set the readonly flag using blockdev.
> 3. Compute the checksum on this block device.
> 4. Mount the ext4 filesytem and then unmount it without doing anything.
> 5. Compute the checksum on the block device (checksum does not match).
>
> The ext4 filesystem still updates the journal on the device and changes
> the whole checksum.
an the partition block device is still read-write.
The read-only flag must be set on the disk and all its partitions. I
guess udev can do this.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Amit
Nov 27, 2012, 8:30:01 PM11/27/12
to
Pascal Hambourg <pascal <at> plouf.fr.eu.org> writes:
> That's because the filesystem is on a partition, not on the whole disk,
> an the partition block device is still read-write.
> The read-only flag must be set on the disk and all its partitions. I
> guess udev can do this.
>
I did this for the block device and the partitions as well. Sorry did
> That's because the filesystem is on a partition, not on the whole disk,
> an the partition block device is still read-write.
> The read-only flag must be set on the disk and all its partitions. I
> guess udev can do this.
>
not clarify this earlier.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pascal Hambourg
Nov 28, 2012, 4:10:02 AM11/28/12
to
Amit a écrit :
I set the partition read-only too. When I mounted the ext4 filesystem on
it, mount detected the flag and mounted the volume read-only. Then I
unmounted the volume. The md5sum remained the same at each step.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50B5CFE2...@plouf.fr.eu.org
> Pascal Hambourg <pascal <at> plouf.fr.eu.org> writes:
>
>> That's because the filesystem is on a partition, not on the whole disk,
>> an the partition block device is still read-write.
>> The read-only flag must be set on the disk and all its partitions. I
>> guess udev can do this.
>
> I did this for the block device and the partitions as well.
Are you sure ?
>
>> That's because the filesystem is on a partition, not on the whole disk,
>> an the partition block device is still read-write.
>> The read-only flag must be set on the disk and all its partitions. I
>> guess udev can do this.
>
> I did this for the block device and the partitions as well.
I set the partition read-only too. When I mounted the ext4 filesystem on
it, mount detected the flag and mounted the volume read-only. Then I
unmounted the volume. The md5sum remained the same at each step.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Amit
Nov 28, 2012, 7:50:01 PM11/28/12
to
Pascal Hambourg <pascal <at> plouf.fr.eu.org> writes:
>
> Amit a écrit :
> > Pascal Hambourg <pascal <at> plouf.fr.eu.org> writes:
> >
> >> That's because the filesystem is on a partition, not on the whole disk,
> >> an the partition block device is still read-write.
> >> The read-only flag must be set on the disk and all its partitions. I
> >> guess udev can do this.
> >
> > I did this for the block device and the partitions as well.
>
> Are you sure ?
> I set the partition read-only too. When I mounted the ext4 filesystem on
> it, mount detected the flag and mounted the volume read-only. Then I
> unmounted the volume. The md5sum remained the same at each step.
>
Thanks for checking your set up.
>
> Amit a écrit :
> > Pascal Hambourg <pascal <at> plouf.fr.eu.org> writes:
> >
> >> That's because the filesystem is on a partition, not on the whole disk,
> >> an the partition block device is still read-write.
> >> The read-only flag must be set on the disk and all its partitions. I
> >> guess udev can do this.
> >
> > I did this for the block device and the partitions as well.
>
> Are you sure ?
> I set the partition read-only too. When I mounted the ext4 filesystem on
> it, mount detected the flag and mounted the volume read-only. Then I
> unmounted the volume. The md5sum remained the same at each step.
>
After reading your mail and seeing that it works for you, it got me
looking at my set up. I am using Linux 3.6.0 from upstream so I reverted
back to current debian wheezy 3.2.x and it worked! So I dug deeper and
found out that 3.6.0 and 3.6.1 had the behavior I described with the
wrong checksums. Kernel 3.6.2 has a bunch of ext4 patches that fixes the
issue (although not sure which patch exactly).
So this solution is good enough for now. Although, I would like to note
that doing an sg_dd (even with readonly flag set) still allows you to
write to the drive.
Thanks for all your help!
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages