4 ms·

As a counterpoint, many daemons or programs (e.g.: sshd, ssh, slurm, munge to name a few) expect their files to have specific users, groups and modes for securi

As a counterpoint, many daemons or programs (e.g.: sshd, ssh, slurm, munge to name a few) expect their files to have specific users, groups and modes for security and behavioral guarantees, and flat out refuse to run if these requirements are not met. When installing these things from archives or moving/distributing relevant files to large fleets, I expect the file contents and all metadata incl. datestamps to be carried the way I want, because all of that data is useful for me and the application which uses the file. If the user doing the copying has no right to copy the file exactly, I either expect a loud warning or an error depending on the situation.

op00to 2y ago
Should the SELinux context of a file always be copied from the source when moving or copying it? Or should it typically inherit the context defined by policy for the destination directory structure? For example, copying a file from a user's home directory (perhaps user_home_t) into /var/www/html/ usually requires it to get the httpd_sys_content_t context (or similar) to be served by the webserver correctly and securely. Blindly copying the original user_home_t context would likely prevent the webserver from accessing the file. Doesn't this suggest that some metadata, specifically the SELinux context, often shouldn't be copied verbatim from the source but rather be determined by the destination and the system's security policy?
- bayindirh 2y ago
  What if the tool accessing the file is malicious, and can copy the file, but can't change the context of the said file? SELinux shall be strict on its behavior even if it's a detriment to user convenience. SELinux contexts shall be sticky, and needs to be manually (re)set after copying. This is the default behavior, BTW. SELinux contexts are not (re)set during copy operations in most cases, from my experience. You need to change/fix the context manually.
  - op00to 2y ago
    I think when I cp a file it takes on the context of the directory or whatever the default context for that path is supposed to be, and when I mv, it retains the original context.
prmoustache 2y ago
That is not what most file copying tools do by default. They usually only do that when you specify it and for good reasons. When foo copy a file from user bar, and put it on his homedir, the last thing h want is for it to be owned by the foo user. Your expectations are irrealistics.
- bayindirh 2y ago
  > That is not what most file copying tools do by default. Yes, and that's OK. > When foo copy a file from user bar, and put it on his homedir, the last thing h want is for it to be owned by the foo user. It depends. > Your expectations are irrealistics (sic). No, rsync can do this (try -avSHAX) and tar does this by default, and we're talking about rsync here.
  - prmoustache 2y ago
    > rsync can do this (try -avSHAX) That is exactly what I am saying, rsync do not do this by default either, you have to tell him to via optionnal parameters.
    - bayindirh 2y ago
      The thing is, if you’re knowledgeable enough to use rsync over cp, you already know relevant flags to do that.

op00to 2y ago

Should the SELinux context of a file always be copied from the source when moving or copying it? Or should it typically inherit the context defined by policy for the destination directory structure? For example, copying a file from a user's home directory (perhaps user_home_t) into /var/www/html/ usually requires it to get the httpd_sys_content_t context (or similar) to be served by the webserver correctly and securely. Blindly copying the original user_home_t context would likely prevent the webserver from accessing the file. Doesn't this suggest that some metadata, specifically the SELinux context, often shouldn't be copied verbatim from the source but rather be determined by the destination and the system's security policy?

bayindirh 2y ago
What if the tool accessing the file is malicious, and can copy the file, but can't change the context of the said file? SELinux shall be strict on its behavior even if it's a detriment to user convenience. SELinux contexts shall be sticky, and needs to be manually (re)set after copying. This is the default behavior, BTW. SELinux contexts are not (re)set during copy operations in most cases, from my experience. You need to change/fix the context manually.
- op00to 2y ago
  I think when I cp a file it takes on the context of the directory or whatever the default context for that path is supposed to be, and when I mv, it retains the original context.

prmoustache 2y ago

That is not what most file copying tools do by default. They usually only do that when you specify it and for good reasons. When foo copy a file from user bar, and put it on his homedir, the last thing h want is for it to be owned by the foo user. Your expectations are irrealistics.

bayindirh 2y ago
> That is not what most file copying tools do by default. Yes, and that's OK. > When foo copy a file from user bar, and put it on his homedir, the last thing h want is for it to be owned by the foo user. It depends. > Your expectations are irrealistics (sic). No, rsync can do this (try -avSHAX) and tar does this by default, and we're talking about rsync here.
- prmoustache 2y ago
  > rsync can do this (try -avSHAX) That is exactly what I am saying, rsync do not do this by default either, you have to tell him to via optionnal parameters.
  - bayindirh 2y ago
    The thing is, if you’re knowledgeable enough to use rsync over cp, you already know relevant flags to do that.