Show HN: Rssfs – An RSS reader written as a file system | Hacker News Reader

Show HN: Rssfs – An RSS reader written as a file system

github.com

78 pointsrhabarba19 comments

  macOS and other non-Windows machines
  sudo ./rssfs

Just what I always wanted; an RSS reader running as root. /s

Why are you using sudo here? FUSE filesystems shouldn't require special privileges unless they're accessing privileged stuff like block devices owned by root.

Iirc, fuse is setuid anyways. Having mount privilege is equivalent to being root on linux.

There's no such thing as a `fuse` system executable on linux.

There is `fusermount` which is indeed suid (so is `mount` btw), but it's also been designed to accommodate unprivileged FUSE mounts and always adds 'nosuid' and 'nodev' mount options when establishing them.

It's not equivalent to being root at all.

https://www.kernel.org/doc/html/latest/filesystems/fuse.html...

That's fair. Unfamiliar about how this works, since ntfs-3g seems to drop root after mounting.

I would still not be comfortable about giving mount permissions to ordinary users (even through a setuid layer since they're known to cause security issues)

You’re right, that would probably not be required.

(This is my first try to play with FUSE. I hope it's still OK.)

Windows support will follow later this year. Maybe. I’d really prefer to have two not-too-diverging code bases here. Need to experiment a bit...

Winfsp maybe? It has a fuse compatibly layer (see fuse.h in the repo).

http://www.secfs.net/winfsp/

I am working on it. Slowly. (see driver-winfsp.go.)

Why does your project require running as root?

It probably does not. I’ll need to understand FUSE better...

Fixed.

I started to think there is a wheel-of-fuse somewhere and people are rolling it to match random things to build as FS.

What's the benefit of offering this via FUSE rather than having a program just fetch the same material and store it in the usual filesystem with the same folder and filenames? I assume there is one and I'm missing it. (Alternatively if this is for learning/experimenting, that's OK! :-))

Not OP, but the benefit of the filesystem implementation is probably to only fetch the data on read.

Which is not really done yet either. I might add that... I’ll work on it tonight (CEST), probably.

Done (poorly).

Having files as common interface has been popular in microkernels and unix for a long time now

We have a lot of tools built to interact with files. A legacy of multiple decades on Unix.

Using that same file "metaphor" to describe resources other than actual blobs to be stored on disk, is surprisingly powerful.

Something which plan9 (& inferno) explored in great depth, and is quite the eye-opening experience. Not much point rehashing the same args again here. If you're interested, check out some youtuve vids, and enjoy the deep dive into an alternative future.

To get something similar on more mainstream OS's, try plan9port and Acme (usually described as an "editor", but its more of a tmux and terminal replacement, which also happens to be able to edit and save text files)

Exposing something as files is kind of like a "protocol". The alternative would have been a library (implemented in a language) that would make things confine itself to the ecosystem of the language. Instead, anyone who can talk to files and directories can interact with this program!

There are applications where this may not entirely be a match though..

Reply on news.ycombinator.com