Hello Alexey!
Alexey Gladkov wrote in
<[email protected]>:
|On Wed, Sep 10, 2025 at 02:37:24PM +0200, Steffen Nurpmeso wrote:
|> Alexey Gladkov wrote in
|> <[email protected]>:
|>|On Tue, Sep 09, 2025 at 11:18:18PM +0200, Steffen Nurpmeso wrote:
|>|> Alexey Gladkov wrote in
|>|> <[email protected]>:
|>|>|On Tue, Sep 09, 2025 at 03:45:33PM +0200, Steffen Nurpmeso wrote:
|>|>|> My distribution (CRUX) updated to 2.9.0, and the build failed via
|>|>|>
|>|>|> cp: failed to preserve ownership for /tmp/.pkgmk/pkg/usr/share/kbd/\
|>|>|> ke\
|>|>|> ym\
|>|>|> aps/i386/qwertz/sr-latin.map.gz: Operation not supported
|>|>|>
|>|>|> Thing is that this seems to only work for real root user, but that
|>|>|> is not who is doing it, really.
|>|>|
|>|>|cp -a is used in the makefile. The -a means no dereference and preserve
|>|>|links and other attributes. This should not be a problem if you have
|>|>|the same user.
|>|>
|>|> GNU coreutils 9.7 cp(1) is of a different opinion:
...
|>|No. This is security settings on your system.
|>|
|>|On my laptop:
...
|> This is really strange; i have no "security setting", actually,
...
|> wherever i try, and so it seems to me the GNU coreutils
|> lib/fchownat.c fallback implementation of lchownat() is bogus
|> thus??
...
|>|>|You can try to change "cp -a" by "cp -dPR". Maybe this will help with
|>|>|fakeroot.
|>|>
|>|> Yes, it does.
|>|
|>|Good. Thanks!
...
|Sorry for delay. You can use the mirror:
|
|https://github.com/legionus/kbd/commit/db82eb6f86e6c0b8ac4260e88b88d66e1\
|cd7c077
Ah oh thanks thanks, i was happy with the normal git view. -dPR
is ok!
...
|> So anyway the commit message of yours is not right ;)
|
|Well, the message reflects my understanding of the situation.
|Perhaps I am wrong.
Sorry to not come back to you after the smoke cleared...
|>, and, do you
|> know people of coreutils, or is this worth a bug report?
|
|No, I don't know anyone from coreutils. But perhaps they should be
|informed about this behavior.
So it is a multifold bug in coreutils for sure:
- they check for a "CHOWN_CHANGE_TIME_BUG" in their autoconf
thing, which seems to derive from some OpenBSD behaviour
according to source file comments (i have not looked at git
history).
- The according check is flaky as it uses sleep(1) in between
stat / chown+stat calls, without potential to specify
a different sleep time that <small>could</small> be necessary.
But regardless that..
- Since fakeroot fails the chown(), but ignores the EPERM error,
the file's timestamp is not updated, causing the autoconf test
to fail thus, causing above mentioned _BUG flag to be set.
- The fallback implementation that is then chosen is in my
opinion broken as it says
so we are required to update ctime. Since lchown succeeded,
we assume that lchmod will do likewise. But if the system
lacks lchmod and lutimes, we are out of luck. Oh well. */
and it then simply uses the return value of l?chmod()
(whatever *that* implementation actually is).
I think it is broken because the actual chown(), which is what
the operation is about, has succeeded.
Due to filesystems like NFS or fuse-based network filesystems
the implementation is inherently racy.
I proposed to simply ignore the result of the chmod() that is
used to cause a change time update -- it should be a best-effort
approach instead:
- result = lchmod (file, st.st_mode & (S_IRWXU | S_IRWXG | S_IRWXO
+ /*result =*/ lchmod (file, st.st_mode & (S_IRWXU | S_IRWXG | S_IRWXO
| S_ISUID | S_ISGID | S_ISVTX));
(Maybe i in person would even solely use utimes, as i *think* in
the code path there is a current stat buffer available anyway.)
- Given it seems i have problems with Paul Eggert, for example
|> (Just wondering, the final cp(1) should work for all
|> configurable cases if config succeeds;
|
|That sounds pretty ambitious! The main goal here is merely for coreutils
|to work on practical platforms.
i cannot imagine coreutils gets a fix, however.
I could be mistaken.
- I proposed to the fakeroot maintainer, whom i place in Bcc,
a granted a little bit fragile change that would cause a change
time update, in that if a stat buffer is known to fakeroot, and
the file belongs the user who runs fakeroot, but the desire is
to make it owned by root:root, .. you know. Let the running
user do with the file what the coreutils fallback does above
(fakeroot yet no utimens at all, so configure mess ahead
otherwise) in the EPERM case (that fakeroot ignores otherwise).
(I think "raciness" and fakeroot do not go together at all,
anyway.)
(To me changing the fakeroot approach would be a real problem
since the build system of my Linux distribution only uses
a build() function to configure, build and install a package.
The approach works for about five years, which likely means
thousands of updates of hundreds of packages, without
a problem.)
Thanks again for your quick kbd fix!!!
Ciao, and greetings from Germany (Hasta la Victoria siempre!)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
