HN Explorer

27 comments

[ 2.4 ms ] story [ 42.6 ms ] thread
neogoose
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

lantastic
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?

Wowfunhappy
> This is practically the most useless project becuase you can not run it without sudo permissions

Well, you could whitelist the tool in sudoers.

This would let LLMs use it too.

ktimespi
Pretty cool to read it directly from the associated device XD

Did you write a metadata parser for most of the filesystems?

[deleted]
(comment deleted)
nomel
> 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.

tough
i have askSudo and askPassword that let the llm ask for one-time sudo use or passwords (without leaking them to their context)
andai
>clankers can not run sudo commands

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!)

tekacs
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:

https://cleanshot.com/share/fgHYMZyz

Terr_
> 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.

Prior discussion: https://news.ycombinator.com/item?id=47931035

vidarh
> An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands

Tell that to the Claude who set up my Raspberry Pi from scratch.

paweladamczuk
It's not useless if it funnels you to the author's other project, fff
rurban
Not only sudo, even ssh into a headless remote device, and survive reboots, and continue the agents session. That's my daily life as an embedded engineer
farmerbb
Just finished reading the README, it was refreshing to read something that wasn't generated by an LLM for a change.
amelius
But can it bypass the magic performed by the SSD controller?

In particular, can it be certain that a flush is really a flush?

4petesake
But can it match the speed and reliability of the venerable Windows Search?
kasabali
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?

Retr0id
It might bypass the fs, but it does not bypass the kernel. Cool, though!
drewg123
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).
wk_end
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 :)

watusername
> bypassing OS kernel

> 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

porridgeraisin
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.

Or if you want to only give fff access,

  sudo groupadd diskreaders
  sudo setfacl -m g:diskreaders:r-- /dev/nvmen01p2
  sudo chown :diskreaders /path/to/fff
  sudo chmod g+s /path/to/fff
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.

noufalibrahim
Isn't this essentially a user space filesystem implementation?
self_awareness
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?