7 ms·

Why not both, like Windows? $HOME/.tmp for user operations and /tmp for system operations? EDIT: I see from other posters it can be done. Why the heck isn't t

Why not both, like Windows? $HOME/.tmp for user operations and /tmp for system operations? EDIT: I see from other posters it can be done. Why the heck isn't this the default?!

yxhuvud 2y ago
What system operations exist that need temp storage shouldn't have a separate user anyhow?
- nullindividual 2y ago
  I see where you're going with your question, but like Windows' Services/scheduled tasks, most of those 'users' don't have a $HOME folder. Not to say they couldn't have one!
  - GoblinSlayer 2y ago
    Services on windows have home folder e.g. in \Windows\ServiceProfiles\LocalService
gspencley 2y ago
IMO even a home-level, per-user tmp directory isn't ideal (though it is better). In a single-user environment, where malware is the biggest concern in current times, what difference does it make if it's a process running under a different user or one that is running under your current user that is attacking you? In other words, for many systems, a home-level temp directory is virtually the same as /tmp anyway since other than system daemons, all applications are being started as a single user anyway. And that might be a security regression. For servers you're spinning up most services at bootup and those should either be running fully sandboxed from each other (containerization) or at least as separate system users. But malware doesn't necessarily need root, or a daemon process user id to inflict harm if it's running as the human user's id and all temp files are in $HOME/.tmp. What you really want is transient application-specific disk storage that is isolated to the running process and protected, so that any malware that tries to attack another running application's temp files can't since they don't have permission even when both processes are running under the same user id. At that point malware requires privilege escalation to root first to be able to attack temp files. And again, if we're talking about a server, you're better off running your services in sandboxes when you can because then even root privilege escalation limits the blast radius.
- nullindividual 2y ago
  > In a single-user environment, where malware is the biggest concern in current times, what difference does it make if it's a process running under a different user or one that is running under your current user that is attacking you? In these systems, the responsibility passes to EDRs or similar. But neither a $HOME/.tmp or /tmp matter in these scenarios. _Shared_ systems are where the concept of $HOME/.tmp might be more interesting.
- pjc50 2y ago
  > In a single-user environment, where malware is the biggest concern in current times, what difference does it make if it's a process running under a different user or one that is running under your current user that is attacking you? Very true, and this is a real weakness of the UNIX (and Windows, even worse!) style security model in the modern environment. Android/iOS do a lot better.
  - marcosdumay 2y ago
    > Android/iOS do a lot better. They would if they were designed with the user's security in mind, instead of Google's/Apple's control. But I disagree, they don't do better at all. Any software that wants to get access to everything just needs to insist.
    - anthk 2y ago
      Check pledge/unveil under OpenBSD. You get isolated software yet with freedoms.
      - marcosdumay 2y ago
        I've recently packed some Linux software in flatpak. It's surprisingly good. Not as good as a real capability-based access control, but quite good compared to the other things that are usable on Linux.
        2y ago
ndsipa_pomu 2y ago
I'm guessing, but I would think that the idea is to have all the junk in one place so that it can be safely cleared at startup and excluded from backups. If the user tmp files were placed in /tmp/${USER}/ then that would achieve the same goal.

Why not both, like Windows? $HOME/.tmp for user operations and /tmp for system operations? EDIT: I see from other posters it can be done. Why the heck isn't this the default?!

yxhuvud 2y ago

What system operations exist that need temp storage shouldn't have a separate user anyhow?

nullindividual 2y ago
I see where you're going with your question, but like Windows' Services/scheduled tasks, most of those 'users' don't have a $HOME folder. Not to say they couldn't have one!
- GoblinSlayer 2y ago
  Services on windows have home folder e.g. in \Windows\ServiceProfiles\LocalService

gspencley 2y ago

IMO even a home-level, per-user tmp directory isn't ideal (though it is better). In a single-user environment, where malware is the biggest concern in current times, what difference does it make if it's a process running under a different user or one that is running under your current user that is attacking you? In other words, for many systems, a home-level temp directory is virtually the same as /tmp anyway since other than system daemons, all applications are being started as a single user anyway. And that might be a security regression. For servers you're spinning up most services at bootup and those should either be running fully sandboxed from each other (containerization) or at least as separate system users. But malware doesn't necessarily need root, or a daemon process user id to inflict harm if it's running as the human user's id and all temp files are in $HOME/.tmp. What you really want is transient application-specific disk storage that is isolated to the running process and protected, so that any malware that tries to attack another running application's temp files can't since they don't have permission even when both processes are running under the same user id. At that point malware requires privilege escalation to root first to be able to attack temp files. And again, if we're talking about a server, you're better off running your services in sandboxes when you can because then even root privilege escalation limits the blast radius.

nullindividual 2y ago
> In a single-user environment, where malware is the biggest concern in current times, what difference does it make if it's a process running under a different user or one that is running under your current user that is attacking you? In these systems, the responsibility passes to EDRs or similar. But neither a $HOME/.tmp or /tmp matter in these scenarios. _Shared_ systems are where the concept of $HOME/.tmp might be more interesting.
pjc50 2y ago
> In a single-user environment, where malware is the biggest concern in current times, what difference does it make if it's a process running under a different user or one that is running under your current user that is attacking you? Very true, and this is a real weakness of the UNIX (and Windows, even worse!) style security model in the modern environment. Android/iOS do a lot better.
- marcosdumay 2y ago
  > Android/iOS do a lot better. They would if they were designed with the user's security in mind, instead of Google's/Apple's control. But I disagree, they don't do better at all. Any software that wants to get access to everything just needs to insist.
  - anthk 2y ago
    Check pledge/unveil under OpenBSD. You get isolated software yet with freedoms.
    - marcosdumay 2y ago
      I've recently packed some Linux software in flatpak. It's surprisingly good. Not as good as a real capability-based access control, but quite good compared to the other things that are usable on Linux.
      - 2y ago

ndsipa_pomu 2y ago

I'm guessing, but I would think that the idea is to have all the junk in one place so that it can be safely cleared at startup and excluded from backups. If the user tmp files were placed in /tmp/${USER}/ then that would achieve the same goal.