Variant symlink implementation with go-fuse

136 views
Skip to first unread message

Paul Jolly

unread,
Mar 18, 2014, 7:22:54 AM3/18/14
to golan...@googlegroups.com
Hi - I am looking to build a fuse-based file system that implements a version of variant symlinks using go-fuse. Some very rough initial code on Github:


The idea being that with time this will accept mount requests of the form:

var-sym-fs <ROOT_DIR> <ENV_VAR_NAME> <MOUNT_POINT>

So for example:

var-sym-fs /home/myitcv/.gos GO_VERSION /home/myitcv/go

with the command:

GO_VERSION=go1.2.1 ls /home/myitcv/go

would list the contents of /home/myitcv/.gos/go1.2.1.

Furthermore (and this is potentially the more powerful use case), PATH, GOPATH etc could be defined to include paths that are themselves variant symlinks. This would take away a lot of the pain for version managers, gvm, rbenv and the like (slight caveat here because there are some important use cases var-sym-fs would not handle where gvm pkgset does, for example local pkgset's)

Ignoring the expense of such a file system (for now at least), I've hit upon an issue that I think relates to this discussion on the LKML

My fuse-based file system works by examining the environment of the calling process in order to resolve the variant symlink. If however that process is performing an execve with a filename argument that corresponds to a file within my fuse file system, I essentially hit deadlock because I can't perform an open on the /proc/PID/environ of the calling process.

The LKML discussion suggests the locking of /proc/PID/environ during an execve is intentional. But my knowledge/understanding of the Linux kernel code is not good enough to verify my anecdotal findings.

Can anyone suggest an alternative approach that might allow this to work? (realising this is not strictly speaking a Go question)

Any feedback greatly appreciated. The code is intentionally very rough right now... until such time as I make headway with the execve issue.

Thanks

Aram Hăvărneanu

unread,
Mar 18, 2014, 7:36:34 AM3/18/14
to Paul Jolly, golang-nuts
Variant symlinks are just an incredibly poor substitute to Plan 9
per-process namespaces.

--
Aram Hăvărneanu

Paul Jolly

unread,
Mar 18, 2014, 9:15:19 AM3/18/14
to Aram Hăvărneanu, golang-nuts
Aram - thanks. You've pointed me in a far better direction:

http://lwn.net/Articles/531114/

Whilst Linux' implementation might not be up to that of Plan 9, the
concept of namespaces seems a far more robust way forward.
--
+447748 105236
pa...@myitcv.org.uk

mikey

unread,
Mar 18, 2014, 9:31:42 AM3/18/14
to golan...@googlegroups.com
Paul, I hope you post back to the list if you get the namespaces concept
working. I have a feeling it could really be useful.

Paul Jolly

unread,
Mar 18, 2014, 9:36:29 AM3/18/14
to mikey, golan...@googlegroups.com
Certainly will.
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
+447748 105236
pa...@myitcv.org.uk

Paul Jolly

unread,
Mar 19, 2014, 11:49:00 AM3/19/14
to mikey, golan...@googlegroups.com
I've published a note on my blog:


Couple of important points:
  • This is just a proof of concept and should not be classed 'production ready'
  • The steps outlined require privilege escalation in a couple of places... I'm not too comfortable with this (perhaps others can comment on alternative ways of achieving the same thing or whether this is a problem in the first instance)
Would welcome any feedback.
Reply all
Reply to author
Forward
0 new messages