From golangci-lint:
> SA1019: rand.Read has been deprecated since Go 1.20 because it
>shouldn't be used: For almost all use cases, crypto/rand.Read is more
>appropriate. (staticcheck)
> SA1019: rand.Seed has been deprecated since Go 1.20 and an alternative
>has been available since Go 1.0: Programs that call Seed and then expect
>a specific sequence of results from the global random source (using
>functions such as Int) can be broken when a dependency changes how
>much it consumes from the global random source. To avoid such breakages,
>programs that need a specific result sequence should use
>NewRand(NewSource(seed)) to obtain a random generator that other
>packages cannot access. (staticcheck)
See also:
- https://pkg.go.dev/math/rand@go1.20#Read
- https://pkg.go.dev/math/rand@go1.20#Seed
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
- Add Target to mount.Mount.
- Add UnmountMounts to unmount a list of mounts in reverse order.
- Add UnmountRecursive to unmount deepest mount first for a given target, using
moby/sys/mountinfo.
Signed-off-by: Edgar Lee <edgarhinshunlee@gmail.com>
This change spins up a new goroutine, locks it to a thread, then
unshares CLONE_FS which allows us to `Chdir` from inside the thread
without affecting the rest of the program.
The thread is no longer usable after unshare so it leaves the thread
locked to prevent go from returning the thread to the thread pool.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Use the IoctlRetInt, IoctlSetInt and IoctlLoopSetStatus64 helper
functions defined in the golang.org/x/sys/unix package instead of
manually wrapping these using a locally defined ioctl function.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
This error was added in c5843b7615, but no longer
used since a5a9f91832, which implemented Windows
support.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The directory created by `T.TempDir` is automatically removed when the
test and all its subtests complete.
Reference: https://pkg.go.dev/testing#T.TempDir
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
gccgo changes the mangling scheme
b483d0e0a2
The change is available in gcc-11, which is the least version that
implements go1.16.
Signed-off-by: Shengjing Zhu <zhsj@debian.org>
Currently, there are few issues that preventing containers
with image volumes to properly start on Windows.
- Unlike the Linux implementation, the Container volume mount paths
were not created if they didn't exist. Those paths are now created.
- while copying the image volume contents to the container volume,
the layers were not properly deactivated, which means that the
container can't start since those layers are still open. The layers
are now properly deactivated, allowing the container to start.
- even if the above issue didn't exist, the Windows implementation of
mount/Mount.Mount deactivates the layers, which wouldn't allow us
to copy files from them. The layers are now deactivated after we've
copied the necessary files from them.
- the target argument of the Windows implementation of mount/Mount.Mount
was unused, which means that folder was always empty. We're now
symlinking the Layer Mount Path into the target folder.
- hcsshim needs its Container Mount Paths to be properly formated, to be
prefixed by C:. This was an issue for Volumes defined with Linux-like
paths (e.g.: /test_dir). filepath.Abs solves this issue.
Signed-off-by: Claudiu Belu <cbelu@cloudbasesolutions.com>
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Go 1.15.7 contained a security fix for CVE-2021-3115, which allowed arbitrary
code to be executed at build time when using cgo on Windows. This issue also
affects Unix users who have “.” listed explicitly in their PATH and are running
“go get” outside of a module or with module mode disabled.
This issue is not limited to the go command itself, and can also affect binaries
that use `os.Command`, `os.LookPath`, etc.
From the related blogpost (ttps://blog.golang.org/path-security):
> Are your own programs affected?
>
> If you use exec.LookPath or exec.Command in your own programs, you only need to
> be concerned if you (or your users) run your program in a directory with untrusted
> contents. If so, then a subprocess could be started using an executable from dot
> instead of from a system directory. (Again, using an executable from dot happens
> always on Windows and only with uncommon PATH settings on Unix.)
>
> If you are concerned, then we’ve published the more restricted variant of os/exec
> as golang.org/x/sys/execabs. You can use it in your program by simply replacing
This patch replaces all uses of `os/exec` with `golang.org/x/sys/execabs`. While
some uses of `os/exec` should not be problematic (e.g. part of tests), it is
probably good to be consistent, in case code gets moved around.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Remove build tags which are already implied by the name of the file.
Ensures build tags are used consistently
Signed-off-by: Derek McGowan <derek@mcg.dev>
It's the only location this is used, so might as well move it
into that package. I could not find external users of this utility,
so not adding an alias / deprecation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
setupLoop()'s Autoclear (LO_FLAGS_AUTOCLEAR) will destruct the
loopback device when all associated file descriptors are closed.
However this behavior didn't work before since setupLoop() was
returning a file name. The looppack device was destructed at
the end of the function when LoopParams had Autoclear = true.
Fixes#4969.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
Trying to reduce duplicated effort in maintaining a mountinfo
parser, this patch replaces the local implementation with the
implementation in github.com/moby/sys, which is actively maintained
and contains various optimizations.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
If a mount has specified `loop` option, we need to handle it on our
own instead of passing it to the kernel. In such case, create a
loopback device, attach the mount source to it, and mount the loopback
device rather than the mount source.
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
`exec.CombinedOutput()` intermittently returns `ECHILD` due to our
signal handling.
`wait(2)`: https://man7.org/linux/man-pages/man2/wait.2.html
> ECHILD (for waitpid() or waitid()) The process specified by pid
> (waitpid()) or idtype and id (waitid()) does not exist or is
> not a child of the calling process. (This can happen for
> one's own child if the action for SIGCHLD is set to SIG_IGN.
> See also the Linux Notes section about threads.)
Fix#4387
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The Err() method should be called after the Scan() loop, not inside it.
Found by: git grep -A3 -F '.Scan()'
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
When m.Type starts with either `fuse.` or `fuse3`, the
mount helper binary `mount.fuse` or `mount.fuse3` is executed.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
