[vim/vim] Vers 9.0.1968 - write any file now => E1509: Error occured when reading or writing extended attribute (Issue #13246)
Gene
Steps to reproduce
On system with SMACK64 in kernel (Arch linux).
Writing any file leads to this error
E1509: Error occured when reading or writing extended attribute
It may be coming from copy ingthe xattr from edited file to backup file and attempting to setxattr.
Possibly around line 1513 of this commit:
https://github.com/vim/vim/pull/13203/commits/23fff2bc6a8a379faf742998e9042269d6b6bb89
and likely because non-priv user cannot write system xattr.
On my system
getfattr -m '' foo shows:
security.SMACK64
and lowly user cannot set security.SMACK64 - which could be the problem.
As of now every file that is written generates this error.
Downstream bug: https://bugs.archlinux.org/task/79830
Expected behaviour
Be able to write files without errors
Version of Vim
9.0.1968
Environment
Arch linux
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I find it surprising, that you are able to edit a file, but not able to update the SMACK64 security attributes. But just to clarify, the file is written successfully (without those attributes) even though it causes those error messages?
I am also wondering, does the attributes get written correctly, are you also using a Vim build which has SMACK feature enabled? Does those copy the SMACK attributes correctly or not? For the time being, you may want to configure with with --disable-xattr. I need some time to reproduce this issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gene
I'm actually not terribly familiar with SMACK but my loose understanding is that there are multiple namespaces for attributes - and while unprivileged user can add/remove the ones in user namespace - they cannot for any attribute in a system namespace. The system namespaces may include trusted, security and system.
The case for every file here is an attribute in the security namespace - non-priv user cannot change these.
vim should only attempt to setxattr() on attributes for which the current user has permission - for non root it can set those such as "user.comment" but it is forbidden from setting "security.SMACK64". I suspect vim code needs to check if it has permission before attempting to set xattrs or at the very least catch the exceptions and not create errors.
So in this case the attributes enforced by the kernel is in the security namespace and
Only root can edit/change security.SMACK64.
security.SMACK64 is enforced by the kernel on every file (unless it is explicitly removed by root).
So with or without vim attempting to setsecurity.SMACK64 it will be set by the kernel. So if I edit any file with any editor including the previous version of vim all files retain their security.SMACK64 attribute.
e.g. perhaps this helps illustrate
$ touch foo
getfattr -m '' foo
# file: foo
security.SMACK64
Do what vim does and make a copy - the security namesapce attributes are enforced by kernel:
$ cp foo goo
getfattr -m '' goo
# file: goo
security.SMACK64
Try to set remove the attribute:
setfattr -x security.SMACK64 foo
setfattr: foo: Operation not permitted
Now if we deal with user namespace and try Set attt it will work fine :
setfattr -n user.comment goo
getfattr -m '' goo
# file: goo
security.SMACK64
user.comment
In line 3147 in os_unix.c the return of setxattr() is ignored and errno is checked. setxattr() returns -1 on error
and sets errno to the list you have coded plus those set by stat().
The man page for setxaatr() is slightly unclear to me what error happens when user has no permission to set an attribute.
Likely its EACCESS. In the case here of simply attempting to copy attributes it is safe to not treat such thing as an error - system and security attributes are enforced by the kernel.
So here's my non-expert suggestions:
-
ONLY report these errno errors when vim is verbose mode.
This routine is merely attempting to "copy" attributes. -
NEVER report errors on EACCESS, ENOTSUP, EPERM and
Again, as you're simply copying attributes, - the system saying "no" is not really an error - certainly not for the security or system namespace ones.
regards
gene
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gene
This patch fixes my problem. I can't say if this is a complete solution, in particular I did not touch line 3061 which may need something similar.
Maybe this helps:
xattr.patch.txt
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gene
Hi - EACCES is actually documented though indirectly via stat - in man page says:
In addition, the errors documented in stat(2) can also occur.
And man 2 stat of course has EACCES :)
I suspect EACCES may be the most likely errno for the situation at hand.
Also quick eyeball on your patch - you need "break;" not "continue;" to break out of switch statement don't you?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
ah thanks, then your patch should be (mostly) fine. Let me include it
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #13246 as completed via 993b175.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gene
Thank you :)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Tomas Sandven
I'm still getting this error on nvim v0.10.0-dev-7ca2d64, which should have this fix included if I'm not mistaken (?)
Version v0.9.4 does not have this error.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Neovim is that way: neovim
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
mikeslattery
I'm guessing these is another latent bug in the code, and this is just a side effect bug. The merged fix is really a workaround for the real problem. Read on for details.
Since I can't comment on the neovim issue, I'm commenting here, but vim code can benefit as well. This is still happening with neovim nightly as of this time. I oddly found that if this fixes it for any given file:
chmod o-rwx file.txt
This is really odd, and I can't explain why this fixed it. I just compared a bad file with a good file. The selinux xattrs were the same, and this was the only other difference.
Workaround fix Neovim for Linux.
I just started having this problem because I just installed a Fedora Linux, but on my prior setup, I configured it so files were written without those bits set.
So, a permanent fix was to add this to /etc/profile (and /etc/zprofile):
umask 027And run this:
chmod o-rwx -R ~—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.