[SOLVED] How can I mount /dev/sda1 read only?

[gerald_clark]

Cut yourself a second initrd with the change you want.

[andyj]

I did that already. That's how I know it works. I posted the patch with the hope that others would see the utility of a read only option so it could be incorporated in the main line, but it looks like I'm the only one building embedded industrial systems.

Andy

[tinypoodle]

Unless "nofstab" is specified in cmdline, disk devices will be added to the fstab, and the device tce is on will be mounted unless "base" is specified. If one does specify "base" then how do extensions get loaded?

TCEDIR  defaults to /tmp/tce.
Optionally 'tce-setdrive' can be invoked.

[tinypoodle]

I posted the patch with the hope that others would see the utility of a read only option so it could be incorporated in the main line, but it looks like I'm the only one building embedded industrial systems.

Feature requests or suggestions are fine, but fall in the competence of the team.
To me that sounds like an additional mode.

All answers given in this thread were based on current system design.

[curaga]

Yes, a ro option sounds good. I would prefer having it as an additional flag and not a tce= replacement.


But adding it does need to take into account that it would prevent any changes. Even with sufficient warnings, what would be the chance that someone tells new users to use it in some tutorial, and then we get posts about how nothing works.

Even now many third-party installers have a bad set of default bootcodes, causing issues for users. I can imagine how one of the installers' authors sees this, decides "hey, our target is USB sticks, read-only is good", and user complaints multiply.

[Rich]

Hi curaga

Even with sufficient warnings, ...

You could set up the flag like this:

Code: [Select]

ro=I_have_only_myself_to_blame_if_this_does_not_work

[roberts]

But when remasters are posted and other unsuspectingly download it and find many tce programs do not work. Folks we have been here before, and that is what lead to the cde directory.

[andyj]

I agree that adding this option would have to be a conscious result of editing the boot config file, as it would have the effect of welding the doors shut. In testing I can mount a virtual disk into the host file system or put a CF card into a reader on another system, but unless a person had another way to physically access the drive like booting from another partition or a usb stick it would be the last thing they ever do on the box. The cde route doesn't accomplish what I'm trying to do, and as I said before it would mount the device rw if it could because the ro option isn't used in it's mount command in tce-setup.

I tested with a separate option initially, so that would work too. I changed it to "tcero" to try to reign in the number of cmdline options. Later on I thought about the other stuff I would like to do, wherein not only is the boot device locked out from writes but maybe disabling things like interactive logins, accessing removable media, ctl-alt-del, X xap, VT switching, etc. I see the choices as:

1. A separate cmdline option to set a "lockdown" mode. A one size fits all, which probably isn't what anybody wants.
2. Separate cmdline options for each lockable option. Could become unwieldy and ugly.
3. A separate initrd with a new "/etc/sysconfig/lockdown-options" file that the boot scripts could look for and in.
4. A separate initrd with the appropriate files patched. Becomes locked to the version it was developed from unless some hooks are put in place.
5. A Wiki HOWTO for #4. Everyone would have to invent their own wheels. Mileage would vary, which would drive up the number of questions.
6. Put in some hooks to help with #4 and #5 above.
7. Some combination of the above.

I wouldn't mind doing some lifting if there was a consensus on the design.

I don't know how to help with people asking about help with a broken remaster. Maybe if there was some sort of TC genuine advantage program...

Andy

[tinypoodle]

Later on I thought about the other stuff I would like to do, wherein not only is the boot device locked out from writes

Note that there is no way for Linux to determine the boot device.

[gerald_clark]

If they can get a command prompt, they can remount the device read-write.
The only useful change I can see would be to change the system to mount the CDE directory read-only, but
still won't stop someone with a command prompt.

[andyj]

Technically yes, the kernel wouldn't have any way to know how it got loaded into memory unless whatever put it there left some sort of clue. The system designer knows which is the boot device and can configure based on that knowledge. In a lockdown mode I would I just use ro for all scsi devices to be safe. For the most flexibility, a boot option could be something like "ro=sda1" or "ro=sda1,sdb1" or "ro=all".

If a person can get a command prompt then you're already pwned. This is why I listed the other possible restrictions in my last post.

Andy

[coreplayer2]

Speaking of clues

In resolving the path to a booted device I create a file named with a ten digit (random) number which is previously stored for example at the root of a remastered ISO. On boot a script runs from bootsync which mounts all devices, searches for that specific number and captures the path using find and sed.   The captured path is useful for other tasks but initially adds an exception to umount allowing all other non booted devices to be unmounted.

I find that technique quit useful when booting one device amongst many possible drives

[gerald_clark]

Why not use blkid and the UUID or LABEL ?

[coreplayer2]

Absolutely in fact LABEL is highly flexible, works better than expected across many devices (except CD's), whilst UUID offers considerably less flexibility being unique to only one device.     Now that I've been introduced to volume label boot codes I use a LABEL with waitusb=5:LABEL=MY_UNIQUE_LABEL boot code exclusively to assist the boot process on my personal devices.   However there are utilities out there which do not respect a LABEL when writing an ISO to USB thumb stick, indeed may even write their own which defeats the purpose.   

Seeding the ISO with a unique identifier file will ensure the script can find and copy my files to the home dir. after the boot process is complete. This technique along with some predictive reasoning can find my files and begin copying them seamlessly within milliseconds.


Didn't want to dilute this thread, was just agreeing with Andyj that a clue can be used effectively.

[andyj]

Now that I've managed to lock TC down somewhat, I've learned that it will take most of the methods I outlined earlier. While inittab is unlikely to change between TC versions and so can be reasonably be safely included in an additional initrd, the same cannot be said for tce-setup. I would still like to see a "mount tce drive read only" kernel command line option. I can live with different configuration files from the mainline since that's why they exist, but I don't like the idea of having to patch code.

Andy