Git security vulnerability announced

One principle I like to use is to assume readers are smart—e.g. in this case, that readers are smart enough to figure out that there are two relevant links to the comments. Of course randomness is also a factor, but it mostly all works out.

There is /etc/profile.d/ which serves much the same purpose for login shells, though PS1 is normally a non-exported shell variable so it wouldn't be inherited. You can configure most other aspects of the shell this way, however. And there is also /etc/bash.bashrc which is read before ~/.bashrc, though it doesn't provide a convenient directory for drop-in scripts by default the way /etc/profile does. It would be trivial to add that if desired. (All based on Debian; YMMV.)

Not technically. Windows permissions follow a "capability" model more than a "user" model. In the Linux user model a user account is always "just one thing". In a "capability" model the user may request different capabilities at different times (based on different needs).

Even in the bad pre-UAC days users didn't have Administrator rights "at all times" in the sense of an Admin account (or group) in the Unix/Posix model, they'd request the capabilities as they needed them and the system would grant them as it saw fit, which was usually just automatic and invisible. The tokens for admin and non-admin stuff were "always" different in Windows. UAC just finally changed it from an "auto-grant" to a "user consents to the grant". UAC wasn't bolted on to the security model of Windows NT, it intercepted token flows that already existed and removed the "automatic" nature of them. (That's why the UAC transition hurt so much at first, especially in Vista, not that it was "bolted" on, but that a lot of software had been built around presumptions about these "automatic" token flows and assumed they were cheap/easy so over-requested them rather than requesting them as rarely or as specifically as truly necessary.)

> Home users got into the habit of only using one user account with admin credentials. It's convenient, but effectively running everything as root.

Not in the Linux sense, no. A home user account isn't "effectively running everything as root". UAC is like sudo in that it acquires a separate user token for subsequent actions. Details about the account may be similar (because of the capability model, the "account" is the same, but the capabilities differ), but they are "distinct" accounts in the Posix reasoning of name+capability.

Large companies that disable UAC and require separate "Admin" accounts are over-reacting/over-correcting, often because they are expecting the Linux/Posix model or because their tools were. UAC is a sudo-like tool: the user tokens are very different on the other side of the UAC fence. Requiring a "physically" separate account is security theater and not very different from just changing UAC from Yes/No flows to "Require Password" flows (unless your auditing tools are bad at their jobs and coalesce tokens with different capabilities based on things like username due to presumptions from Posix systems). It's silly to manage twice as many accounts when you can just make UAC stricter and require passwords. (And also Microsoft's several decades of research show that "Require Password" flows are themselves security theater, people don't actually think longer about UAC prompts if they have to type their password in more often, it just trains them to type their password in more often, which makes it easier to phish their passwords.)