pkg / xattr Goto Github PK

To be safe against symlink race attacks I propose to use the system call variants that do not follow symlinks for Get, Set and List. Even though they look different, all platforms have such a variant:

• lgetxattr / lsetxattr / llistxattr on Linux
• SYS_EXTATTR_GET_LINK / SYS_EXTATTR_SET_LINK / SYS_EXTATTR_LIST_LINK on FreeBSD
• XATTR_NOFOLLOW on Darwin

If you agree that this is a good idea I will send a PR. This will make having correct and safe xattr support in gocryptfs much easier.

thought-machine/please#1268

Hi,

while using the xattr package I noticed that the API stutters a lot, e.g. the XAttrError type needs to be referred to from external code as xattr.XAttrError. It would be much nicer to rename it to Error, so that the referral would look like xattr.Error instead. It's the same with the functions, xattr.Get() instead of xattr.Getxattr() would reduce the stutter a lot.

Are you interested in a PR which fixes this? If not, please feel free to close this issue (and I'm going to live with the stutter ;).

I would like for

func (e *Error) Error() string {
    if e.Name != "" {
        return e.Op + " " + e.Path + " " + e.Name + ": " + e.Err.Error()
    } else {
        return e.Op + " " + e.Path + ": " + e.Err.Error()
    }
}

since I do not want the superfluous space returned from xattr.go's list's errors in my log files:

hi, on debian10.4 ,i got this "xattr.Set /tmp/foo1 root.test: operation not supported"

package main

import (
	"fmt"
	"github.com/pkg/xattr"
)

const path = "/tmp/foo1"
const prefix = "root."

func main(){
	if err := xattr.Set(path, prefix+"test", []byte("test-attr-value")); err != nil {
		fmt.Println(err)
	}
	if list, err := xattr.List(path); err == nil {
		fmt.Println(list)
	}

	if data, err := xattr.Get(path, "ceph.dir.files"); err == nil {
		fmt.Println(string(data[:]))
	}

}```



`


OS:4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
golang: go version go1.11.6 linux/amd64
dpkg -l  golang-github-pkg-xattr-dev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                        Version      Architecture Description
+++-===========================-============-============-=================================
ii  golang-github-pkg-xattr-dev 0.4.0-1      all          Extended attribute support for Go`

misspell (via Go Report Card) suggests s/neccessary/necessary/.

...Since June 15th, 2021, the building on travis-ci.org is ceased.

I have go program which utilizes xattr lib and it gives me fake errors while writing xattr

func writeXattr(path, name string, data []byte, l log15.Logger) {
	err := xattr.Setxattr(path, name, data)

	if err != nil {
		l.Error("Setxattr failed", "err", err, "name", name, "path", path)
	}
}

example of log message
EROR[03-24|15:27:52] Setxattr failed module=tests url=http://curl.haxx.se/rfc/rfc1635.txt uuid_low=983ca2a62a257759 file=/tmp/pztest/0e/0e319b3e1d23aef6458258df630b92b0 err="setxatt
r /tmp/pztest/0e/0e319b3e1d23aef6458258df630b92b0_part user.h.Server: errno 0" name=user.h.Server path=/tmp/pztest/0e/0e319b3e1d23aef6458258df630b92b0_part

File itself contains all xattrs which I set. So I had to come up with following workaround to prevent
those non-existent errors to pollute my logs:

func writeXattr(path, name string, data []byte, l log15.Logger) {
	err, ok := xattr.Setxattr(path, name, data).(*xattr.XAttrError)
	if ok && err.Err.(syscall.Errno) != 0 {
		l.Error("Setxattr failed", "err", err, "name", name, "path", path)
	}
}

Hi,

a user of restic reported that they get the error cannot allocate memory, running restic on Linux (CentOS 7) on amd64 here.

Do you maybe have any idea where this comes from? Why would xattr.List() return this error?

Thank you very much for your work!

9943167

src/github.com/pkg/xattr/xattr_linux.go:34:7: undefined: errors.Is

On Linux and Darwin at least, xattr.List returns ENOTSUP when the operation is not supported on a file. On Solaris, the openat call fails with EINVAL for the O_XATTR flag. This presumably applies to all operations, but in restic/restic#3839 we have a failure from List specifically.

We could fix this in restic, but since pkg/xattr already tries to simulate the Linux/BSD interface on Solaris, maybe this library could change the EINVAL to ENOTSUP and make porting to Solaris easier for everyone?

Would a PR be considered that added Illumos support? It would require usage of cgo.

I'm trying to package xattr for Debian. The tests fail with:

go test -v -p 4 github.com/pkg/xattr
=== RUN   Test
--- FAIL: Test (0.00s)
    xattr_test.go:23: xattr.Set /tmp/179974020 user.test: operation not supported
FAIL

@fd0 @rfjakob @harshavardhana - question:
What do you think (for this project) about replacing travis build by github action?
How many go versions do we want to support?

This is on Fedora 27, where /tmp is a tmpfs mount:

$ df -Th /tmp
Filesystem     Type   Size  Used Avail Use% Mounted on
tmpfs          tmpfs  3.9G   12M  3.9G   1% /tmp

Tests fail because the Supported() check does not seem to work:

$ go test
--- FAIL: Test (0.00s)
	xattr_test.go:27: xattr.Set /tmp/572738598 user.test: operation not supported
--- FAIL: TestNoData (0.00s)
	xattr_test.go:77: xattr.Set /tmp/017916237 user.test: operation not supported
FAIL
exit status 1
FAIL	github.com/pkg/xattr	0.002s

xattr.Set causes panic on Darwin (16.5.0) when it encounters com.apple.rootless which is valueless.
/bin is an example of this.

$ xattr -l -x  /bin
com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00  |........@.......|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020
com.apple.rootless:
00000000

Panic:

panic: runtime error: index out of range
goroutine 1 [running]:
github.com/pkg/xattr.Set(0xc4222bedc0, 0x1a, 0xc4222beb80, 0x12, 0x1954f70, 0x0, 0x0, 0x0, 0x0)
	src/github.com/pkg/xattr/xattr_darwin.go:50 +0x38d

Test case:
err = Set(tmp.Name(), "com.apple.rootless", []byte{})

I'm not familiar enough with Go, the code or other requirements to propose a fix for this other than to just skip it when len is 0.

fyi: i hit this during a restore with restic.
thanks.

Hi,

first, thanks a lot for tagging a release! I appreciate that a lot!

I noticed that the code is not formatted with gofmt, and you've removed the call to goimports (which checks for that) from the Travis tests. Was that intentional? Will you accept a small PR from me which adds it back?

Thanks!

A restic user recently reported a problem where reading of xattrs from a SMB1 mount point failed with an error "numerical result out of range", which is error 34, ERANGE.

Turns out that it works with SMB2, but for SMB1 the problem is probably due to what's summed up in xattr/xattr#42, and the workaround is to make the buffer given to syscall.Listxattrs() one byte larger than the reported-to-be-needed size.

Would you be happy with a PR that changes buf := make([]byte, size) to buf := make([]byte, size+1) in xattr_linux.go (or just make the change yourself, that's fine by me!)?

Someone said they're going to take a look at it upstream, but a workaround here would probably be nice.