This commit adds a new function LookupNameBySid that wraps
LookupAccountSidW and works as an inverse of the already existing
LookupSidByName. In addition to offering new functionality, this
fixes#202.
Signed-off-by: Michael Hofmann <michael.hofmann@bitgestalt.com>
Since Go version 1.13, the standard library has built-in support for
wrapping and unwrapping of error values. This commit bumps the minimum
version required by the module from 1.12 to 1.13, replaces all calls to
errors.Wrap/f with fmt.Errorf and removes the now unneeded dependency on
github.com/pkg/errors.
Signed-off-by: Michael Hofmann <michael.hofmann@bitgestalt.com>
TestLookupEmptyNameFails was an identical copy of TestLookupInvalidSid
in the same file. This commit changes the account name queried by the
former to an empty string which is what the name of the test case
suggests.
Signed-off-by: Michael Hofmann <michael.hofmann@bitgestalt.com>
A recent OS change altered how sparse files are represented in backup
streams. This caused backuptar to no longer work with certain files. The
specific behavior that changed is as follows:
- Empty sparse files (size = 0), previously did not have any data or
sparse block streams in the backup stream. Now, they will have a
data stream with size = 0, and no sparse block streams.
- Sparse files with a single allocated range (e.g. a normal file that
has the sparse attribute set) previously would not show as sparse in
the backup stream. Now, they will show as sparse.
The old backuptar behavior assumed that if the sparse flag was set on
the data stream, then there would always be a set of sparse blocks
following. These changes break this assumption, and so require special
handling.
It is unsupported to have a data stream, marked sparse, that contains
file content AND a series of sparse block streams following. As far as
I can tell this is not a valid case for backup streams.
This change also cleans up some code and error messages, and expands on
the test coverage for backuptar.
For more information on backup stream format see: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-bkup/f67950c8-d583-469a-83dd-c4ff4cedf533
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
This change updates the README to mention that we now require a valid
DCO on every commit via the bot. Also adds a new contributing section
that houses this info.
This change also re-orders the README into sections:
Contributing, Code of Conduct, Special Thanks
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
These packages had incorrect error handling for their generated syscall
bindings. The functions they were calling returned errors directly, but
the binding was written such that the generated code was calling
GetLastError instead.
Thankfully, this did not affect the detection of whether or not an error
had occurred, it only caused the value returned in the case of an error
to be not the right error code.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
Even though this repo is normally used as a dependency, there are some
sample binaries and tools built out of here. This just makes sure they still build
in the CI.
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
We don't support actually using ETW on windows/arm, but to make things
easier for downstream dependencies, we want to still allow the package
to compile and just no-op on this architecture. We do this by returning
a nil Provider, and implementing its methods to no-op when the receiver
is nil.
Previously this was implemented by putting NewProviderWithID in
provider_unsupported.go, but when we refactored the code so that the
actual work was done in NewProviderWithOptions instead, we didn't fix up
provider_unsupported. This change fixes this by putting only
NewProviderWithOptions in provider_unsupported.go, since the other
provider creation functions call into this one.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
We also get pre-defined constants instead of carrying our own copies.
However, this changes the public API winio.FileBasicInfo from using
syscall.Filetime to using windows.Filetime, as visible in
backuptar/tar.go.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
At this point points of difference between the three local
mksyscall_windows.go implementations and
golang.org/x/sys/windows/mkwinsyscall v0.0.0-20210104204734-6f8348627aad
are:
- pkg/etw: Deduplicates imported functions due to multiple calling APIs
- pkg/security and vhd: Forced UTF-16 mode, not checking A/W suffix. I
also removed cosmetic differences between these two implementations.
`go generate` reports no changes with these updates.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
This moves all the current users of
$GOROOT/src/syscall/mksyscall_windows.go to instead use
golang.org/x/sys/windows/mkwinsyscall, as directed by the version of the
former in Go 1.15.
It also syncs the local forks of mksyscall_windows.go with the latest
version of golang.org/x/sys/windows/mkwinsyscall/mkwinsyscall.go, so
that the local patches can be easily seen in a side-by-side comparison.
Significant changes compared to the in-tree forked versions:
* *bool parameters are read back through a temp-var, not directly like
other pointer parameters.
* ?-suffixed function names support testing for function presence before
calling. This replaces a local implementation of this in
pkg/security, which was not actually used anyway. The upstream version
correctly supports functions that don't already have an error return.
* `errnoErr(0)` is now useful, so each call of `errnoErr` doesn't need
to be protected with a check for 0 first.
* The generated functions are now sorted. This of course produced a
*lot* of churn in the generated files.
vhd\vhd.go was changed to generate syscalls into zvhd_windows.go, since
regeneration removes the build tag added by hand in
9d8277341f.
After all that, I also ran
```
go generate . .\pkg\etw\ .\pkg\process\ .\pkg\security\ .\vhd\
```
to update all the existing generated code.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
On Windows, the os/exec.{Command,CommandContext,LookPath} functions resolve command
names that have neither path separators nor file extension (e.g., "git") by first
looking in the current working directory before looking in the PATH environment
variable.
Go maintainers intended to match cmd.exe's historical behavior.
However, this is pretty much never the intended behavior and as an abundance of
precaution this patch prevents that when executing commands.
This patch was prompted by the [Go 1.15.7 security fixes](https://blog.golang.org/path-security).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/sirupsen/logrus/compare/v1.4.2...v1.7.0
logrus v1.7.0 removes dependency on github.com/konsorten/go-windows-terminal-sequences
Features:
* a new buffer pool management API has been added
* a set of `<LogLevel>Fn()` functions have been added
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Michael Hofmann