Copying an executable file or rules to the /usr/bin/ or /rw/config/ doesn’t create proper copy of the file in the /usr/bin/ or /rw/config/ but instead creates a file that is recognized as unknown (greyed, cross in the icon) and cannot be executed (permission denied?).
Command: sudo cp file /usr/bin/
Alternative: I created a link from the file and tried to sudo cp that link → the same issue, unrecognized file as well
Templates affected, brand new vanilla templates: whonix-workstation-17, debian-13-xfce, fedora-12-xfce, all AppVMs
I am not sure if there was any design change that causes this. I am using the sudo cp in these folders for years without any issues, until now.
To Be Status
sudo cp works as intended - creates a copy of the files in the required destination.
You might be losing ownership of your files when copying. sudo executes the command as root, created files belong to root, not the owner of the original file.
Run cp with -p or --preserve=ownership to preserve the original ownership.
Having that said, you probably don’t want to own files in /usr/bin or /rw/config. Just copy them as root (making root the owner) and allow execution to everyone or just the target group.
Just copy them as root (making root the owner) and allow execution to everyone
How do I do that? I am also using these in my script and the cp does the same as above - files in the /etc/udev/rules.d/ as well as /etc/systemd/system/ → not recognized.
You probably don’t want to know this, but it could be a change of “umask”, which limits the permissions which get applied on file creation. The concept of umask appears in quite a lot of places.
man umask might be useful, or your favourite Linux book…
You probably don’t want to know this, but it could be a change of “umask”, which limits the permissions which get applied on file creation. The concept of umask appears in quite a lot of places.
man umask might be useful, or your favourite Linux book…
I noticed this just now. It doesn’t make sense when sudo doesn’t do what it is supposed to do. The operation in the terminal also doesn’t notify you that it didn’t go through as intended.
Do we know what changed in the past that caused this issue that was not present few months ago? I believe it is a bug.
I cannot reproduce it here on Qubes 4.2.4, and I am a bit disappointed. I find unmask is 0022 everywhere I look, so the only permission that is removed is the “write” one.
You can just type umask to test the user account, and sudo bash -c umask to test the sudo environment.
There are excellent reasons for making it difficult to make dangerous mistakes. This is why umask is a long-time safety feature of Unixy shells. It can be overridden, but in almost every case it is better to add an extra step to an unusual command, so that mistakes are more difficult in the common case.