You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think using mv is slightly invalid in this use case, if we're nuking the /tmp/tmp. dir in exit/etc traps anyway in the cleanup function an install command to copy the reencrypted file or plain old copy would be less problematic as then rename() won't fail with EPERM underneath of mv if the underlying filesystem doesn't support rename() in this way.
Worthy of a pr to swap mv to copy or install instead here?
Ref from rename() on linux (note this is nixos 23.11 if it matters but its more glibc than anything):
EPERM or EACCES
The directory containing oldpath has the sticky bit
(S_ISVTX) set and the process's effective user ID is
neither the user ID of the file to be deleted nor that of
the directory containing it, and the process is not
privileged (Linux: does not have the CAP_FOWNER
capability); or newpath is an existing file and the
directory containing it has the sticky bit set and the
process's effective user ID is neither the user ID of the
file to be replaced nor that of the directory containing
it, and the process is not privileged (Linux: does not
have the CAP_FOWNER capability); or the filesystem
containing oldpath does not support renaming of the type
requested.
In this case we're hitting EPERM in mv via rename() and that last condition in that rename on this tmpfs fs is saying no in spite of the dir in /tmp and file being owned by my user.
The text was updated successfully, but these errors were encountered:
With this layout:
I get this when trying to edit an existing secret:
This looks to be this mv:
agenix/pkgs/agenix.sh
Line 188 in 24a7ea3
I think using mv is slightly invalid in this use case, if we're nuking the /tmp/tmp. dir in exit/etc traps anyway in the cleanup function an install command to copy the reencrypted file or plain old copy would be less problematic as then rename() won't fail with EPERM underneath of mv if the underlying filesystem doesn't support rename() in this way.
Worthy of a pr to swap mv to copy or install instead here?
Ref from rename() on linux (note this is nixos 23.11 if it matters but its more glibc than anything):
In this case we're hitting EPERM in mv via rename() and that last condition in that rename on this tmpfs fs is saying no in spite of the dir in /tmp and file being owned by my user.
The text was updated successfully, but these errors were encountered: