Should functions to safely handle paths, as in libpathrs, be in std?

[ron minnich]

Background: there is a new project starting up, called kuties, or k4s, which is a small image, based on u-root, implementing a kubernetes appliance. This is something like k3s, but we would like to use the gobusybox (from u-root) to get a smaller footprint than the 384M used by k3s (it is large because it embeds full binaries, i.e. many, many copies of the Go packages, unlike u-root).

Skip this para if you know what u-root is ... U-root and the gobusybox are probably unfamiliar to many of you, here is a precis:

The go busybox uses the ast package to transform programs into packages, then builds the resultant set of packages into one binary. (github.com/ju-root/gobusybox). It works for anything that can be built with 'go build'. The full process takes 20s for 165 or so programs.

The gobusybox requires that programs it imports be buildable with go build, and, further, statically linked. 

I've been looking at systems like runc, and notice they have a dependency on libpathrs, which: 

"implements a set of C-friendly APIs (written in Rust) to make path resolution within a potentially-untrusted directory safe on GNU/Linux. There are countless examples of security vulnerabilities caused by bad handling of paths (symlinks make the issue significantly worse)."

This dependency on external Rust libraries makes things difficult for pure Go environments such as u-root; further, libpathrs *support* being limited to Linux is an issue, as some of the security vulnerabilities (e.g. around symlinks) are not just on Linux. 

Further, the libpathrs *implementation* has deep dependencies on Linux. 

Hence,this note, and why I'm asking on golang-dev, and not -nuts: does something like libpathrs exist somewhere in a Go package? Should it, more properly, be in filepath as a set of functions, or in some other std package? This feels a bit like crypto: never roll your own, which is kind of what is happening out there. 

If you're going to tell me this should be a proposal, I'll go that path, I was not quite sure how to ask the question. 

Thanks

[Sean Liao]

https://pkg.go.dev/os#Root

- sean

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/CAP6exY%2BK1CSVbjO0jmpwExtO%2BtmTNXh%3Dw2SOBOOYdRPKiOXcjg%40mail.gmail.com.

[Goran]

`github.com/google/safeopen` is a third option in the same space, a bit narrower in scope than pathrs-lite.

For k4s I'd start with `os.Root` and reach for pathrs-lite only when you hit something it doesn't express. Both are gobusybox-friendly.

As for "should it be in stdlib as more primitives" — some of it now is, and the os.Root surface is still being filled in. If you find a concrete gap (a primitive libpathrs has that you need and neither `os.Root` nor pathrs-lite covers), that's a real proposal and a good one. But "does Go have anything here" is answered.

And you're right that it's crypto-shaped. Don't roll your own.

[Damien Neil]

FWIW, os.Root supports (I believe) every filesystem operation supported by the os package. Its main limitation at the moment is that it doesn't always use the fastest available kernel APIs; for example recent Linux kernels have an openat2 syscall which can handle most of the safe-path-lookup behavior much more efficiently than os.Root's userspace implementation.

- Damien

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-dev/1823c5c7-9945-409b-bec4-eb33ad286574n%40googlegroups.com.

[ron minnich]

Thanks, everyone. This has been really helpful. 

github.com/u-root/k4s

This will take a while, but I've discovered there is some interest. 

To view this discussion visit https://groups.google.com/d/msgid/golang-dev/CAGgfL4uW7rwzbUizqK3SAiMAVijVsKnWzu5j0f7iktuyY0z%2BDA%40mail.gmail.com.