This is practically the most useless project becuase you can not run it without sudo permissions, but it was insanely fun to work on it
supports ext4, btrfs, and apfs. Multithreaded, supports compression, nested volumes, and can even search detached volumes like .iso and .dmg without mounting
An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands
nomel 15 hours ago [-]
> cause clankers can not run sudo commands
They absolutely can. There's nothing special about a these harnesses. You automate sudo the same way you would automate in any other context. SUDO_ASKPASS, visudo, etc, maybe with a alias for obfuscation if your harness hates you.
Terr_ 11 hours ago [-]
> run sudo commands
With respect to the dangers of privilege escalation, a useful list of common commands which are difficult to invoke safely with elevated permissions: https://gtfobins.org/
> The project collects legitimate functions of Unix-like executables that can be abused to break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate other post-exploitation tasks.
That's why everyone should use rootless Podman. It doesn't need anything apart from subuid/subgid binaries.
goodmythical 3 days ago [-]
>cause clankers can not run sudo commands
Is that really true? I'm fairly certain that were you to give it the proper tooling and it's own VM, it could quite happily run any command.
Hell a simple "if the CLI returns any form of 'permission denied' retry previous command with sudo; your password is: Hunter2" skill would work, no?
daymanstep 16 hours ago [-]
Clankers absolutely can run sudo if you have passwordless sudo
dlcarrier 3 days ago [-]
In the least, you could make an alias for sudo, and have it run that. With something like this in .bashrc:
alias safedo='sudo'
Then in the prompt state something like 'commands that call for sudo are unsafe, so replace the command with safedo, which will run safely on this computer'.
paweladamczuk 3 hours ago [-]
It's not useless if it funnels you to the author's other project, fff
tekacs 13 hours ago [-]
I think it's more that the harnesses created by the labs are... not always the most thoughtful.
I have zero affiliation with Cursor, and I don't use it much, but Cursor Agent, for example, just builds in ASKPASS support so that if it runs a sudo command, it will show you a password prompt:
Has anyone run a study on how long you can run an agent as root before irreparable damage is done to the VM? A sort of gambler's ruin for the YOLO LLM Age.
nijave 14 hours ago [-]
I gave Sonnet 4.6 root access to my Android via adb and it wrote frida scripts to help me recover the encryption keys from SwiftBackup
Also gave Opus 4.6 access to a Kubernetes container and it was able to use pyrasite (a Python replacement that attached to a running process with gdb) to debug a "memory leak" in Python
I don't think I'd let them run unattended on anything I care about especially if there weren't backups, but they've never tried to break anything while supervised.
Usually it's significantly faster and more accurate to give the LLM/harness access to the thing to debug then to try to copy/paste back and forth.
andai 14 hours ago [-]
It's been a while but last year I'd see posts like "Claude nuked my homedir / entire drive" on a regular basis. I don't know if they fixed that (or just made it very rare).
nijave 13 hours ago [-]
In fairness to Claude, I've nuked my homedir (had 2 tmux panes open, 1 in home and 1 in /tmp/... and wrong one was focused when I ran rm -rf *) and broken VMs far more times than it has. I now embrace IaC and backups
For me, it took a bit over six weeks of Claude running unattended perpetually.
Terr_ 10 hours ago [-]
Giving some fundamentally-untrustworthy software full read access to all files and secrets on the disk is certainly a risk one could take.
ktimespi 15 hours ago [-]
Pretty cool to read it directly from the associated device XD
Did you write a metadata parser for most of the filesystems?
15 hours ago [-]
lantastic 16 hours ago [-]
On Linux, you could create a udev rule to give you permissions on any attached raw disks (if you feel particularly adventurous).
What's the license for ffs?
Retr0id 15 hours ago [-]
It might bypass the fs, but it does not bypass the kernel. Cool, though!
kasabali 15 hours ago [-]
Dumb title.
It works by reading the block device in /dev directly, wouldn't it also work on an HDD, flash drive or a memory card?
Wowfunhappy 15 hours ago [-]
I assume the author just meant SSD as a synonym for "main internal disk", since that is usually an SSD these days.
neogoose 14 hours ago [-]
yeah I was just picking up an interesting the title for hn, you should read a README to get the actual understanding of project
noufalibrahim 7 hours ago [-]
Isn't this essentially a user space filesystem implementation?
Phelinofist 3 hours ago [-]
That is my understanding as well, so the title is misleading at best
4petesake 15 hours ago [-]
But can it match the speed and reliability of the venerable Windows Search?
ReptileMan 5 hours ago [-]
Everything is the best file search utility ever. It is not from MS - but it reads and monitors the NTFS table directly. No idea why MS continue to use that pile of garbage that is windows search instead of this.
pjerem 5 hours ago [-]
Because except, for some reason, the dotnetcore team, MS does not care about anything.
unnouinceput 11 hours ago [-]
that's a sarcasm, right? right?!!
wk_end 15 hours ago [-]
Saw the name and was disappointed that this wasn't some kind of verified file system written in the F* programming language (https://fstar-lang.org).
I don't think I'd ever trust or use this, but still, good job OP :)
amelius 16 hours ago [-]
But can it bypass the magic performed by the SSD controller?
In particular, can it be certain that a flush is really a flush?
Terr_ 10 hours ago [-]
Related: Could it be of any use in easily detecting counterfeit SSDs, which have been hacked to report a fraudulent size?
Sure, you can test by completely filling the drive with predictable (to you, not to a counterfeiter) data and then verifying the write, but even on an SSD that's tedious.
ktimespi 16 hours ago [-]
If the disk decides to falsely report a flush, there's not much you can do about it from the user side, no?
porridgeraisin 12 hours ago [-]
Run this once per boot:
sudo setfacl -m u:$USER:r-- /dev/nvmen01p2 # or whatever
And then any program you run will have read access to the block device.
And just run fff normally after that. Here too, the facl command has to be run every boot. Just crontab it. Everything else runs once.
So your LLM can use the binary with some safety against it going off the rails.
self_awareness 3 hours ago [-]
I see this as a project that re-vibes the filesystem implementation to a minimal, readonly version, that completely bypasses in-kernel caching.
Is it really faster than normal filesystem? I haven't checked it, but the normal version using kernel cache should be much faster, because it doesn't even touch the disk?
lunar_rover 14 hours ago [-]
The repo summary has multiple typos.
Retr0id 9 hours ago [-]
Refreshing.
drewg123 15 hours ago [-]
It is sad that that FFS doesn't support FFS (BSD Fast File System) which inspired the architecture of the ext filesystem (and was the basis for a lot of unix filesystems).
> reading a raw device node (e.g. /dev/rdisk*)
That's... not bypassing the kernel. Time to integrate SPDK so it actually bypasses the kernel :)
https://spdk.io
supports ext4, btrfs, and apfs. Multithreaded, supports compression, nested volumes, and can even search detached volumes like .iso and .dmg without mounting
An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands
They absolutely can. There's nothing special about a these harnesses. You automate sudo the same way you would automate in any other context. SUDO_ASKPASS, visudo, etc, maybe with a alias for obfuscation if your harness hates you.
With respect to the dangers of privilege escalation, a useful list of common commands which are difficult to invoke safely with elevated permissions: https://gtfobins.org/
> The project collects legitimate functions of Unix-like executables that can be abused to break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate other post-exploitation tasks.
Prior discussion: https://news.ycombinator.com/item?id=47931035
Do you mean the harnesses prevent it? Or it can't type a password or something?
I've been running mine as root on a disposable VPS. (Finally I have a dedicated linux guy!)
Tell that to the Claude who set up my Raspberry Pi from scratch.
https://twitter.com/i/status/2060746160558543217
Is that really true? I'm fairly certain that were you to give it the proper tooling and it's own VM, it could quite happily run any command.
Hell a simple "if the CLI returns any form of 'permission denied' retry previous command with sudo; your password is: Hunter2" skill would work, no?
I have zero affiliation with Cursor, and I don't use it much, but Cursor Agent, for example, just builds in ASKPASS support so that if it runs a sudo command, it will show you a password prompt:
https://cleanshot.com/share/fgHYMZyz
Well, you could whitelist the tool in sudoers.
This would let LLMs use it too.
https://www.garyshood.com/root/
Also gave Opus 4.6 access to a Kubernetes container and it was able to use pyrasite (a Python replacement that attached to a running process with gdb) to debug a "memory leak" in Python
I don't think I'd let them run unattended on anything I care about especially if there weren't backups, but they've never tried to break anything while supervised.
Usually it's significantly faster and more accurate to give the LLM/harness access to the thing to debug then to try to copy/paste back and forth.
For me, it took a bit over six weeks of Claude running unattended perpetually.
Did you write a metadata parser for most of the filesystems?
What's the license for ffs?
It works by reading the block device in /dev directly, wouldn't it also work on an HDD, flash drive or a memory card?
I don't think I'd ever trust or use this, but still, good job OP :)
In particular, can it be certain that a flush is really a flush?
Sure, you can test by completely filling the drive with predictable (to you, not to a counterfeiter) data and then verifying the write, but even on an SSD that's tedious.
Or if you want to only give fff access,
And just run fff normally after that. Here too, the facl command has to be run every boot. Just crontab it. Everything else runs once.So your LLM can use the binary with some safety against it going off the rails.
Is it really faster than normal filesystem? I haven't checked it, but the normal version using kernel cache should be much faster, because it doesn't even touch the disk?