How do I set a directory and all its sub-folders read-only in Linux...

-maxdepth with the find command

Probably be more helpful if you explained what you needed it for or what you were trying to accomplish vs arbitrary shit where you clearly don't know what you are doing.

:)

Fuck off namefag, havent you gotten BTFO'd enough times?

Why would I care?
This shit is anonymous.

I want what you anons have been suggesting, except that I want it to work in at most a couple seconds even if I have say millions of subdirectories under the one that I'm applying the command to. This is what "Preferably without having to traverse it" means.
In principle it should be possible, there isn't any technical limitation to having a filter in the kernel that says "prevent any filesystem calls to create or write to paths beginning with /home/user/myreadonlydir/".

I-i-ts anonymous. Im going to use a name.

Oh, you want SELinux.

>and shouldn't be necessary in principle
Yes, it should. Files can be directly referenced without checking their location in the tree for write permissions, because that takes more time and is stupid.

And I'm also aware I can do it by having a different filesystem mounted ro, but I'm looking to do it within a single filesystem.
Ultimate purpose as I mentioned is controlling what the OS writes to disk. I just don't want it saving random data to random parts of the disk without me knowing about it first, so that if somebody manages to get the files in plaintext form at least I know they're only getting what I intended to write to the disk in the first place.

>I want what you anons have been suggesting, except that

set user permissions instead of file permissions

would it not be easier to make fstab mount the whole drive or directory as read only?

You could create a BTRFS snapshot of the tree you want to preserve and then just sync shit back to find out what had changed.

>controlling what the OS writes to disk
is your impression that when someone copies a file, they get all the random bits that are left from other files?

Or are you saying in case they have access to a whole chunk of hard drive space / memory?

It only would take a couple microseconds at most to check if there IS a blacklist of non-zero length in the first place (basically a single int comparison), so you only take the penalty if you put things into the list. And it also could be made into a module or a compile-time option so the performance penalty is really minuscule.
Besides, sometimes features win against performance, such as with filesystem journaling and security features (stack randomization, spectre mitigations, like the other user said SELinux).

How so? Are you sure SELinux does this?

From what I can tell it sounds like he wants some kind of autistic panic button that locks down his filesystem but at the same time doesn't break his OS.

SELinux policies can do exactly what you are asking, they are just super hard to setup.

just use FDE with a 20+ character passphrase and change it every year/month/week depending on autism levels.

In case, say, the government gets ahold of my hard-drive and a judge rules I have to give them the decryption password or rot in jail forever.

mount -obind,ro /writeable/path /readonly/path

Wouldn't work if files were already open, shit could still be written.

Nah, I'm aware I'm going to have to manually set or unset the read-only permissions. Thanks for the tip about SELinux policies, I'll check it out.

See Yeah that sounds like it could work too

I don't think you can bind mount a directory over itself, that's the problem. Would have to move every dir I want to lock down to an alternate location

Problem is on most distro processes run mostly under the same user, and even then I don't think you can just lock down a directory for certain users and not for others, it depends on the permissions set on sub-directories and files inside and you can just block things that happen at the first level of depth.

read-only data is still readable.

Are you trying to generate a random encryption passphrase at boot? Yes I suppose you wouldn't be able to divulge the passphrase, but you would also never be able to turn off your computer without losing all data.

He's trying to limit where the OS writes, so the gov can't grab snippets of CP off his hard drive.

I'm assuming the hard drive itself has nothing incriminating on it - so decryption alone isn't the problem. It is that the OS has accidentally written shit all over the place, and you don't know what they can pull from that. Is that correct?

I'm not familiar with latest methods, but what about running everything in a ram drive.

But giving or restricting OS directory access doesn't have anything to do with where physically it is writing data.

No I'm not storing anything illegal (except maybe ranting about the jews once in a while on Jow Forums), I'm just tired of OSes writing all kinds of private data all over the place and the user having no control over it.
It's always frightening reading about say normies getting busted for leaking corporate data because some forensic investigator found some log file buried deep into the filesystem showing that say an USB drive was plugged in the machine on a given date and things like that.
And also malware and OS corruption would be more rare if the system files were locked down by default like they are on Android.

You may want to consider using a WM instead of a full blown DE. DEs are more prone to saving "recently opened" documents/files and other stuff to make life easier.

You can also scour your hard drive and link directories to tmpfs in fstab or individual files to /dev/null

example of tmpfs in fstab
tmpfs /var/log tmpfs defaults,noatime,mode=1777 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.cache/thumbnails tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.cache/mozilla/firefox tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.thumbnails tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.cache/media-art tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.adobe tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.macromedia tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.config/freshwrapper-data tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.cache/chromium tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.cache/totem tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/worm/.dvdcss tmpfs defaults,noatime,mode=1777 0 0

systemd-nspawn --ephemeral can create an advanced "jailed" chroot that uses a temporary BTRFS snapshot of your entire system.

Then you use a randomly keyed dmcrypt volume on a cache disk, format it and use aufs to create a hybrid filesystem with the snapshot being read only and all writes being done to the cache disk.

Then when you power your shit down, the key for the cache is lost, and the only remaining data is what you started with.

> those commands will go through every subdirectory recursively, which takes a lot of time and shouldn't be necessary in principle
It's not necessary only where you have set access control to inherit the permissions of the topmost directory (some prefix / infix regex or whatever) Which however then of course has runtime costs beyond checking permissions on one thing only.

Can be done, but it is not recommended - you'll be using selinux or such a monster.

Just use acls or linux permissions and do that one recursion, k? It's not like your drive is too slow to access the likely more files that are in those directories, right?

Firejail should help a good bit and be less taxing to work with than SELinux.

Also containers and VMs if you must.

>I was hoping there was a single attribute for directories that blocked writes at any level down the tree
are you fucking retarded? stick to windows you dumb fucking faggot. they like to hold your hand as much as possible, which sounds like what you're looking for. god damned kids these days.

What makes you so upset bro?

this is the correct answer

What about running a os entirely from a write protected usb/cd live disk thing.w Regularly restart and you'll loose anything you didn't save to the ssd/hdd.