Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mount only /ipfs/ #2187

Open
Kubuxu opened this issue Jan 11, 2016 · 8 comments
Open

Mount only /ipfs/ #2187

Kubuxu opened this issue Jan 11, 2016 · 8 comments
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) topic/fuse Topic fuse

Comments

@Kubuxu
Copy link
Member

Kubuxu commented Jan 11, 2016

Mounting /ipns/ has negative consequences (one can't use ipfs name publish) so option to mount only /ipfs/ or /ipns in read only mode would be beneficial.

@hackergrrl
Copy link
Contributor

Can you describe what happens when you try to ipfs name publish while /ipns is mounted?

I'm unable to repro: I can still publish properly with /ipns mounted.

@whyrusleeping
Copy link
Member

when you run a publish while you have ipns mounted, the updated value doesnt propogate to the fuse code.

@hackergrrl
Copy link
Contributor

Is the solution then to have a workaround (this issue) or would it make more sense to have the changes propagate to the mounted fuse FS? (I ask this with no notion of how non-trivial it is.)

@whyrusleeping
Copy link
Member

having changes propogate to the fuse mount is non-trivial and not the solution we're going to go for
the thing we want for this issue is essentially ipfs mount --ipns=/ipns only mount /ipns, and ipfs mount --ipfs=/ipfs only mount /ipfs

@hackergrrl
Copy link
Contributor

We should also either disable ipfs name publish when /ipns is mounted with write privileges, or at very least warn.

@whyrusleeping
Copy link
Member

Yeah, i totally thought that ipfs name publish was disabled while the mount was active... thats a bug

@whyrusleeping whyrusleeping added kind/bug A bug in existing code (including security flaws) help wanted Seeking public contribution on this issue labels Aug 19, 2016
@djdv djdv self-assigned this May 14, 2019
@djdv djdv added the topic/fuse Topic fuse label May 14, 2019
@benaryorg
Copy link

benaryorg commented May 2, 2020

This also blocks ipfs mount while --routing=none is set.
I've added a bounty for this over on Bountysource: badge

@djdv
Copy link
Contributor

djdv commented May 2, 2020

For what it's worth I have an implementation that separates the mount options via their namespace and was looking to speak with someone about restrictions like these. I can imagine having a shared locking mechanism that allows the mount to be active without (permanently) preventing things like publishing, so long as the systems share the same path lock. (basically just have the mount hold a lock for a key if it's in use, and if not allow publish while blocking specific operations on the mount temporarily)

While this mechanism is in place, the stability of the actual (new) mount implementation is still in progress. This shows off some of the flexibility of it though
https://www.youtube.com/watch?v=IBRLt_ibct8
allowing to dynamically mount and unmount various APIs the node understands to various places on various operating systems using various backing apis (like fuse, winfsp, and 9p). Lots of variety...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) topic/fuse Topic fuse
Projects
None yet
Development

No branches or pull requests

5 participants