Kitz Forum
Computer Software => Linux => Topic started by: sevenlayermuddle on November 21, 2019, 04:14:11 PM
-
As mentioned elsewhere, I’ve spent some time this week messing around with a data disk in a CentOS box. The disk has a few partitions, mounted at various places in hierarchy. To facilitate this work I manually stopped the various services that might access the disk’s partitions, and then unmounted the partitions.
All went well, the work is complete. But it occurred to me as an afterthought... if there was anything I’d overlooked that might try and access these partitions, it might end up writing to the unmounted mount points? A candidate would have been my overnight backup script, which writes things to one of these partitions and in fact that nearly happened, except the script failed last night for other reasons.
So my question... is there anything I could, or should have done, or permissions I should set, to protect the mount points from being written during the time the partitions were unmounted?
-
Any partitions which aren't mounted are simply unavailable space. Nothing can write to them (apart from low level functions such as format, which can normally only be run by root).
-
Maybe I didn't explain it very well.
Specific actual example: I have a directory named /mythtv/default. It is the default place in which TV recordings get stored. And in my /etc/fstab file, I specify that a specific partition gets mounted at /mythtv/default. That ensures that my TV recordings are guaranteed to have a certain amount of space available, and also guarantees that they won't won't run riot and consume the entire disk.
So in normal running /myth/default is actually mapped to a specific parition (/dev/sdb2 in fact, identified in /etc/fstab by its UUID).
But if /dev/sdb2 is unmounted, then /mythtv/default simply becomes a directory within the filesystem of the parent directory and writing to /mythtv/default would consume space on an unintended disk. Also, the data written would also become invisible once /dev/sdb2 was mounted on top.
Both of the things in above paragraph would be bad things, and I'm just wondering if there is some way I could make these things impossible, rather than depending on own perfection?
-
I suspected that was what you were asking but I was unable to answer promptly.
I would be inclined to test that the physical partition is actually mounted on the mount-point, within the file system tree, before allowing any write (or read) process to take place.
-
This might work if the TV recording software fails if it tries to write in to a non-existent directory. If you kept the mount the same but created a base directory within the mounted partition called (say) data, could you configure the TV recordings to store in /mythtv/default/data by default? If the partition isn't mounted that directory wouldn't exist.
-
These suggestions may avoid the Myth problem.
But Another partition user is a nightly cron job, that produces a .iso that is a snapshot of everything that matters to me. It is designed to ‘always succeed’ so in the event of directories not existing, it creates them. Yes I could change that, but I like it as it is.
I was really hoping somebody might surprise me by telling me I could protect the mount points with simple permission settings.
-
I have found a suggestion elsewhere of using chattr to make the underlying mount point immutable, Eg, with the partition unmounted...
Chattr +i /mythtv/ default
Chattr is not a thing I am familiar with, or have ever used, but I may try it tomorrow and report back on success. Meanwhile of course, encouragement/discouragement obviously welcomed. :)
-
I do not think you can easily protect against general mounts. For specific mounts an alternative to your chattr is
mkdir -p /mythtv/default
chmod a-rwx /mythtv/default
Whether or not nested files can be created is down to a design decision within software. In some cases the program will assume that an installation procedure has been performed and that the destination directory exists. In others an absent directory tree will be created on the fly. Unmounting is adequate to protect against the former. The latter relies on permissions being locked down.
Remember that most everything in Unix or Linux is a file. Programs accessing them do not care what kind of filesystem they are on, whether symlinks are involved, and so on.
-
The point is, I know I can avoid writing to unmounted mount points by just not doing so. I can also contrive hierarchies that do not do so. But I seeking a method that makes it very unlikely do so, even by mistake.
Or for that matter, prevents another user from doing so, by mistake or by lack of communication. The only other user is my other half who is also privy to root credentials. But whilst it is unlikely we would both be logged in doing system admin tasks at the same time, it is not impossible.
Actually however I think chattr +i might be doing the trick.
Tested by (as root)...
mkdir /testmnt
chmod 777 /testmnt
chattr +i /testmnt
Attempting to create a file (still as root) now fails
>/testmnt/a
-bash: /testmnt/a: Operation not permitted
Now mount a partition there...
mount /dev/sdb2 /testmnt
I can now create a file
>/testmnt/a
.. no error
Even as a non privileged user
>/testmnt/a2
.. no error
Am I missing something, is there a downside?
-
Ps: *Assuming (?) there’s no forum etiquette breached by linking to discussions in other respectable places, here’s where I found the chattr idea...
https://serverfault.com/questions/570255/prevent-the-possiblity-of-writing-data-to-an-unmounted-mount-point-directory
*Otherwise tell me and I’ll delete, or (admins) just delete.
-
That's no problem.
-
:)
-
Very interesting, I had no idea that this method existed and seems a good idea to apply to my backup drive mountpoints.
-
I’ve not really got my head around it tbh, but it does seem to provide the protection I wanted.
I worked on Unix system development for a living once upon a time and whilst I may simply have forgotten, I have no recollection of anything comparable to chattr (etc) but in these days (SVR4 early days) linux-based Operating Systems were virtually unknown. Not sure whether it was resident on CentOS 7 by default, or if it is part of a package I subsequently installed.
-
This is interesting: https://en.wikipedia.org/wiki/Chattr
A file with the i attribute cannot be modified.
It cannot be deleted or renamed, no link can be created to this file and no data can be written to the file.
When set, prevents, even the superuser, from erasing or changing the contents of the file.
Makes it sound like its almost an accident it works the way it does for mount points.
-
Yes it seems to go some way beyond what can be achieved with the basic rwx permissions.
I do vaguely recall, mid 1990s, about the time I was moving on to greener pastures, ACLs were appearing in Unix and confusing my simple view of the world. Even so, iirc, ACLs were just glorified permission controls. File attributes like ‘immutable’ seem to have crept in while I wasn’t looking. :)
I have the impression that in order to accidentally write to an immutable directory, even as root, one would have to first accidentally execute ‘chattr -i’, which does not seem likely.
-
It's the mount point which is made immutable with the +i switch. A remote file system can still be mounted by root at that mount point, after which you can write to the remote file system. At no time do you write to the mount point itself. So there's no mystery here.
-
It occurs to me there is one downside to using the immutable attribute. It is the fact that my brain became full some time ago, and can no longer be relied upon to store new knowledge.
If, at some future time I ever want to delete or rename the mount point, I may spend rather a lot of time figuring out why it won’t let me do so. For I’ll have long since forgotten that I found chattr and made it immutable. And unless I check using lsattr (which I’ll also have forgotten about), it doesn’t seem to be obvious that immutability is the issue. :D
-
I know what you mean - I'm conscious of the same issue. I try to deal with it by keeping an organised notes program running at all times, and adding a note whenever I encounter something I don't want to forget. So I've added a note about chattr and lsattr now. I use a program called Keepnote.
-
But do you remember you've made notes? ::)
-
:oldman:
I've got into the habit using Keepnote frequently, with all notes indexed by category and a lot of cross-references. Hopefully I will remember to look there when I need to.
-
Keepnote does look useful.
I’ve always tried (not always successfully) to keep detailed logs & records of the things that I do to home tech. There’s a logbook for each machine for example that contains a history of initial build, maintenance, upgrades etc. I try to record the reasons for whatever decisions had to be made, as well as the implementation detail.
But in my case, these are just plain text documents or in early days, actual paper books. Something with better indexing would indeed be useful. :)
-
Keepnote does look like a good idea, but the last release (0.7.8) was in March 2012. 0.7.9 was made available for pre-release testing in July 2012 and has stagnated. The last update on the issue tracker appears to be 2015.
I'd want something that ran on Android as well with the ability to sync to my desktop (using Google drive, Dropbox or OneDrive etc.).
-
:oldman:
I've got into the habit using Keepnote frequently, with all notes indexed by category and a lot of cross-references. Hopefully I will remember to look there when I need to.
Many thanks for the reference Eric, had not seen this utility before, looks very useful indeed, have had a little play on Windows 10 platform and a read at the help files.
I religiously make notes of my projects & activities when fresh in my mind but frequently can't remember where I stored the notes, strange that a storage location can make perfect sense on creation but seem totally illogical a month later, likely an age thing !
Hopefully this utility will help.
-
One other habit I’ve adopted for quick and easy spontaneous note taking, that’s accessible from all my devices and needs no special Apps, is to compose an unaddressed email and save it in gmail’s ‘drafts’ folder. It can then be viewed later on other devices that connect to same gmail. I speak for Apple devices, but I assume Android/Linux/Windows clients would all work too.
I could of course just send myself an email but that would add clutter to my inbox and sent items, leaving it in ‘drafts’ avoids that clutter.