The code uses ByteSliceFromString first, which
- checks that the string does not contain \0;
- copies the string to a byte slice which ends with \0.
Next, it does one more copy, to sa.raw fields.
Double copying is not needed because:
- the code already checks that there's an extra byte for \0 in the
sa.raw field;
- there is no need to check for \0 byte in the middle of the fields
(those are hash and cipher names, and an unknown name will result in
EINVAL from the kernel).
While at it, remove the use of magic numbers.
Change-Id: I0cf096fad6f974507d4aa8d429f077000b3bb639
Reviewed-on: https://go-review.googlesource.com/c/sys/+/527836
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Test helper functions mktmpfifo and chtmpdir were written
before t.Cleanup was available, which necessitated returning
of a cleanup function and the use of defer.
Let's use t.Cleanup (available since Go 1.14) and simplify the callers.
While at it,
- use t.Helper (added in Go 1.9);
- simplify some error messages (errors that come from os package
usually doesn't need to be wrapped).
Change-Id: Id981ae1c85fa2642a76358a31fc18a9af2f78711
Reviewed-on: https://go-review.googlesource.com/c/sys/+/526695
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Mostly change that to os.Create(filepath.Join(t.TempDir(), "filename"))
so that the cleanup is done automatically (and, because this is a new
directory, we do not need to have a "create unique temp file name"
logic).
While at it, fix some log/error messages -- if an error is coming from
e.g. os package, it is already wrapped, so there's no need to add more
context.
Change-Id: I62f13679f256b94095be5ca1e77a3fa302f01b97
Reviewed-on: https://go-review.googlesource.com/c/sys/+/526298
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
Add wrappers for sched_getattr(2) and sched_setattr(2), as well as
various SCHED_ values usable for these.
The kludge in linux/types.go is needed so we can include both
linux/sched/types.h (for struct sched_attr) and sched.h (for a few
defines from include/bits/cpu-set.h).
Unfortunately, they both define struct sched_param, thus the need to
mask one of the definitions.
Change-Id: I3e13cf49ccef7ae81a75d33826d18de84a52106d
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/sys/+/516756
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
CL 126516 added support for flags argument, implemented in the same way
as glibc does (it tries to guess what the kernel would do).
CL 246537 added using faccess2(2) Linux syscall which supports the flags
directly. For older kernels, though, the syscall is not available, and
the code uses glibc-like fallback.
There is one very specific scenario in which the fallback fails.
The scenario involves all these conditions:
- no faccessat2 support available (i.e. either Linux kernel < 5.8,
or a seccomp set up to disable faccessat2);
- the current user is not root (i.e. geteuid() != 0);
- CAP_DAC_OVERRIDE capability is set for the current process;
- the file to be executed does not have executable permission
bit set for either the current EUID or EGID;
- the file to be executed have at least one executable bit set.
Unfortunately, this set of conditions was observed in the wild -- a
container run as a non-root user with the binary file owned by root with
executable permission set for a user only [1]. Essentially it means it
is not as rare as it may seem.
Now, CAP_DAC_OVERRIDE essentially makes the kernel bypass most of the
checks, so execve(2) and friends work the same was as for root user,
i.e. if at least one executable bit it set, the permission to execute
is granted (see generic_permission() function in the Linux kernel).
Modify the code to check for CAP_DAC_OVERRIDE and mimic the kernel
behavior for permission checks.
This is essentially the same fix as CL 468735 for Go syscall package.
Tested on CentOS 7 with the repro similar to the one from [2].
[1] https://github.com/opencontainers/runc/issues/3715
[2] https://github.com/golang/go/issues/58552#issuecomment-1432505621
Change-Id: I726b6acab6a6e6d0358ef98e6a582b405c347614
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/sys/+/468877
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This changes some fields of openbsd Statfs_t from arrays of int8
to arrays of byte. This makes the types of those fields correspond to
the types used on most other BSD systems (Darwin, FreeBSD, NetBSD),
and simplifies the conversion to Go string.
Similar changes: CL 359674, CL 259903, CL 74331.
Note that while this patches mkpost.go, the end result is obtained by
manual editing of ztypes_openbsd_*.go files. The reasons for this are:
1. automatic regeneration (tried on openbsd 6.9 / amd64) brings in way
too many changes (5 files changed, 193 insertions, 45 deletions).
2. I could not figure out how to run openbsd on non-amd64.
Nevertheless, this change is sufficient, meaning if someone will
actually end up regenerating these (see e.g. CL 347649) after this
commit is merged, the fields will still be kept as arrays of byte.
Change-Id: I4520889f11f6ac2d9befe17c7a77186198c08cd2
Reviewed-on: https://go-review.googlesource.com/c/sys/+/407195
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: 谢致邦 <xiezhibang@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
CL 340370 introduced (*Ifreq).Name method which scans the Ifrn field
for \0 twice -- first explicitly, when by calling BytePtrToString.
It seems more straightforward to use ByteSliceToString instead. The
differences are:
- simpler code;
- no double scanning for \0;
- in case there is no \0 in the Ifrn (unlikely), the full string
(rather than an empty string) is now returned.
With the last item in mind, the test case with no \0 as input that
expects empty output fails, so drop it. Alternatively, we could test
that it returns the full string, but it will be essentially testing
ByteSliceToString, which is not the point.
Cc: Matt Layher <mdlayher@gmail.com>
Change-Id: I31d4f6dbe98aae5120f9b2246c93ceaa6a165395
Reviewed-on: https://go-review.googlesource.com/c/sys/+/407194
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The close_range(2) syscall is available since Linux kernel v5.9,
with additional functionality of CLOSE_RANGE_CLOEXEC since v5.11.
No tests are required since this is a bare syscall.
Change-Id: I410470e3713e2005cc7acf24d1347938fe05ef63
Reviewed-on: https://go-review.googlesource.com/c/sys/+/301409
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
openat2 is a new syscall added to Linux 5.6. It provides a superset of
openat(2) functionality, extending it with flags telling the kernel how
to resolve the paths.
For more info, see https://lwn.net/Articles/803237/
NOTE that this is a second attempt to add the call; the previous one
(https://golang.org/cl/227280) was reverted
(https://golang.org/cl/227846) due to the test case failure on ARM
(https://golang.org/issue/38357).
This CL has the test case reworked to be less assumptive to the testing
environment. In particular, it first tries if the most simplistic
openat2() call succeeds, and skips the test otherwise. It is done that
way because CI can be under under different kernels and in various
envrionments -- in particular, Docker+seccomp can result in EPERM from a
system call (which is not expected otherwise).
For previous discussions about the test case, see
https://golang.org/cl/227865.
Change-Id: I4276cf13dc29ecbdbdc9c58da0f76270f585a67f
Reviewed-on: https://go-review.googlesource.com/c/sys/+/253057
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
openat2 is a new syscall added to Linux 5.6. It provides a superset
of openat(2) functionality, providing a way to extend it in the future,
and (for now) adding flags telling the kernel how to resolve the path.
For more info on openat2, see https://lwn.net/Articles/803237/
A primitive test case is added to check that Openat2 works as
it should. Tested to skip on kernel 5.5 and pass on 5.6.
Change-Id: Ib8bbd71791762f043200543cecdea16d2fd3c81d
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/sys/+/227280
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Add IoctlRetInt() for ioctls that use syscall's return value
as an output parameter. Add a unit test for Linux, and the
NS_GET_ defines that it requires (see ioctl_ns(2)).
Motivation:
Currently, x/sys/unix provides a few functions to deal with ioctls.
In particular, IoctlGetInt(), which "performs an ioctl operation
which gets an integer value". It does that by passing a pointer
to an integer to a syscall and returning that integer. The value
returned from syscall is treated as success/failure flag
(0 means success, -1 means failure, and in such case errno
is used to figure out the underlying error).
It appears that there are a few ioctls in Linux and at least one
in Solaris, which do not use the above way to return an int, instead
they use the syscall's return value (in case it's not negative).
As Linux ioctl(2) man page says,
> RETURN VALUE
> Usually, on success zero is returned. A few ioctl() requests
> use the return value as an output parameter and return
> a nonnegative value on success. On error, -1 is returned,
> and errno is set appropriately.
Currently I am aware of at least 6 Linux ioctls that do that
(return the value directly):
* LOOP_CTL_* ioctls on /dev/loop-control (all 3 of them). Source: loop(4)
* NS_* ioctls (3 out of 4) on /proc/PID/ns/*. Source: ioctl_ns(2)
And one in Solaris:
* I_FIND ioctl, source: streamio(7i).
There might be some more ioctls like the ones above, but since
ioctls are scarcely documented, it is hard to say how many more.
Obviously, using IoctlGetInt() for such ioctls would be a big
mistake, as 0 will always be returned. For example, there was
a bug in Docker's pkg/loopback (moby/moby#39801).
[v6: make it linux-specific for now]
Fixesgolang/go#33966
Change-Id: Ie64f72fd84101b955ba14519a357e06a66d685d0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/192780
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Kir Kolyshkin