Live data from Hacker News

Show HN: boxxy – Control where Linux programs put files, without symlinks

github.com

21–30 of 250 posts

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#22

This seems like a great idea, thank you for sharing. Are you aware of any notable caveats to using Boxxy, given the mount-based implementation? E.g., will this continue to work if you sync ~/ with other machines (rsync, FTP, SyncThing)?

> This seems like a great idea, thank you for sharing.

Thanks :D

> Are you aware of any notable caveats to using Boxxy, given the mount-based implementation?

System configuration to allow mount namespaces, tools might have to understand recursive paths, it's tested for my use-cases.

> E.g., will this continue to work if you sync ~/ with other machines (rsync, FTP, SyncThing)?

I haven't tried it! Would love to see what happens as that's unfortunately not a use-case I have.

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#23
post #9
post #8

AWS an interesting example considering it's also a default search path for the SDK so anything using an AWS SDK is going to check for ~/.aws/config; does boxxy apply the rules to anything run in a shell, or only if 'run by boxxy'?

Only in the latter case; I didn't want to assume how people want things done, and implicitly magical tools break more often than not in my experience. You may also be able to tell I don't have a lot of AWS experience (:

I suppose that is indeed more trouble than it's worth. As for applications that might behave like AWS and their SDK; I think that if someone uses boxxy they would probably also remember to do the same thing for other stuff that uses aws under the hood, so overall a win either way!

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#26

This is very cool and would massively simplify how I build my dotfiles. Is there any way this could support macOS?

> Is there any way this could support macOS?

I don't use macOS often-enough to know for sure, but a quick search suggests that bind-mounts (or similar) are more complicated on macOS. Not against the idea tho!

Edit:

> and would massively simplify how I build my dotfiles.

I guess I should tell r/unixporn at some point, huh? (:

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#27
post #17

Earlier quoted context omitted.

Would be cool if there was a tool that could detect that configured path was attempted to be opened, and redirect the open() syscall to the real path... But that would most likely require kernel support. Boxxy seems good enough for userspace.

I actually attempted using ptrace to rewrite syscalls first! It was... horribly painful, and didn't work anywhere near as well as the bind-mount version.

In the past I used something like inotab to use an inotify-based trigger to pipe data from SSH to a different system that didn't have any NAS or SAN support, it might also work to detect 'who' is touching any files that boxxy has previously seen rules for.

Perhaps still too tricky to make it do magic things and break programs in the process, but it could be used to audit who's working with what paths and let the user print a report so they know what apps to boxx up and make them behave.

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#28
post #17

Earlier quoted context omitted.

Would be cool if there was a tool that could detect that configured path was attempted to be opened, and redirect the open() syscall to the real path... But that would most likely require kernel support. Boxxy seems good enough for userspace.

I actually attempted using ptrace to rewrite syscalls first! It was... horribly painful, and didn't work anywhere near as well as the bind-mount version.

Fun fact, one layer of App Engine's sandbox from a couple years ago was implemented using ptrace. It will redirect filesystem IO to in-memory files.

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#30
post #17

Earlier quoted context omitted.

I actually attempted using ptrace to rewrite syscalls first! It was... horribly painful, and didn't work anywhere near as well as the bind-mount version.

In the past I used something like inotab to use an inotify-based trigger to pipe data from SSH to a different system that didn't have any NAS or SAN support, it might also work to detect 'who' is touching any files that boxxy has previously seen rules for. Perhaps still too tricky to make it do magic things and break programs in the process, but it could be used to audit who's working with what paths and let the user…

That is an excellent idea! Something like could definitely be worth adding. It's why there's a "remount rootfs as ro" flag; that way anything not specified in rules is ro and misbehaving programs will explode.
Post reply on HN