This is a kernel rather than a setfacl bug. The bug was introduced in
v4.9-rc1 by commit 07393101, and fixed around v4.13-rc4 by various
commits depending on the filesystem used. The ext4 fix is a3bb2d55.
Here are some details:
commit 073931017b49d9458aa351605b43a7e34598caef
Author: Jan Kara
2015-02-10 9:05 GMT+01:00 László Böszörményi (GCS) g...@debian.org:
Still fails on kFreeBSD.
Then I will need a little help, please: can you debug what happens
when patch tries to traverse_path() dir/foo/bar? It should try to
openat() subdirectory foo in dir, the openat() should fail with
errno
2015-02-10 19:28 GMT+01:00 László Böszörményi (GCS) g...@debian.org:
Then I will need a little help, please: can you debug what happens
when patch tries to traverse_path() dir/foo/bar? It should try to
openat() subdirectory foo in dir, the openat() should fail with
errno == ELOOP, and patch
2015-02-05 10:01 GMT+01:00 László Böszörményi (GCS) g...@debian.org:
On Wed, Feb 4, 2015 at 11:10 AM, Andreas Grünbacher
andreas.gruenbac...@gmail.com wrote:
make check should pass in the latest snapshot:
[...]
Could you give it a try?
Made my mistake. As I've to follow upstream development
make check should pass in the latest snapshot:
ftp://alpha.gnu.org/gnu/patch/patch-2.7.4.6-7297.tar.gz
Could you give it a try?
Thanks,
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
It turned out that not allowing arbitrary symlinks causes many
git-style kernel patches to fail:
https://lkml.org/lkml/2015/1/26/522
Therefore, patch has been changed to resove paths in user space now;
patch-2.7.4 should behave properly again.
--
To UNSUBSCRIBE, email to
This depends on try_tempname going into gnulib first which is pending;
after that, fixing the failure should be very easy.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Note that by default, patch-2.7.4 will still refuse to treat symlinks
as files and
replace them with patched versions of the files the symlinks point to
by default.
This behavior can be achieved with the --follow-symlinks option, though.
--
To UNSUBSCRIBE, email to
2015-02-02 15:00 GMT+01:00 László Böszörményi (GCS) g...@debian.org:
On the other hand, upstream #44149 [2] will be fixed later, right? I
think the best would be to disable that test on non-Linux platforms
for now.
Well, it's a bug the test suite triggers that needs to be fixed. I'm not very
This is also causing problems with kernel patches:
http://thread.gmane.org/gmane.linux.kernel/1874498/
It's a bit of a hairy problem; we are currently trying to find a better
solution that doesn't break too many other things.
Thanks,
Andreas
--
To UNSUBSCRIBE, email to
I've pushed code to forbid symlinks with .. components. That's the
best we can do for now I believe. Implementing path traversal in user
space, making sure it is used everywhere, and making it reasonably
fast and portable seems too much in short term.
--
To UNSUBSCRIBE, email to
Before git-style patches, patch could assume that symlinks in the
working directory are safe to traverse; it only needed to ensure that
pathnames of files it creates weren't absolute and didn't contain '..'
pathname components.
Patch now creates symlinks. Forbidding absolute symlinks and '.' and
This fix in the upstream git repository should take care of this bug.
diff --git a/NEWS b/NEWS
index 42afed7..d3f1c2d 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,8 @@
differs from patch instead of File ... is not empty after patch; not
deleting.
* Function names in hunks (from diff -p) are now
Well I hope those are fixed as well now.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
14 matches
Mail list logo
