traceroute:
...
15 213.136.2.6 35.049 ms 34.440 ms 34.338 ms
16 213.136.2.20 34.814 ms 33.359 ms 35.116 ms
17 213.154.229.42 33.837 ms 33.572 ms 34.794 ms
18 213.136.8.188 30.174 ms 28.810 ms 33.674 ms
tcptraceroute ... 23 :
...
15 213.136.2.6 28.626 ms 28.657 ms 28.849 ms
16 213.136.2.20 28.608 ms 28.483 ms 28.515 ms
17 213.154.229.42 27.989 ms 28.058 ms 29.336 ms
18 * * *
Identity management is a mess on Azure! I still cannot understand the difference between app registrations and enterprise applications, and how they tie into service principals.
They also have a lot of different resources, such as Graph API, Entra ID.
Manage identities are simpler, since they are Azure constructions, so they work more or less like a IAM role. But then you try to use them with Entra ID APIs and things fall apart.
Sign In with Apple is allowing you to "create an account"(author's words) on @company.com, which should not be supported in the firat place. Instead, it should rely in a central directory controlled by company.com for authentication
"Create an Apple account with support@company.com email"
Wait - how is that workflow possible and supported?
In my head, authorization under @company.com would be delegated to a central directory, instead of relying on Apple ID. It is effectively an authentication bypass.
- CS: Have a staging (production-like) environment for proper validation. It looks like CS has one of these bu they have just skipped it
- IT Admins: Have controlled roll-outs, instead of doing everything in a single swoop.
- CS: Fuzz test your configuration
It is possible Cloudflare did a timepointed release on this. Controlled roll-outs wouldn't work if all the daily chunked updates didn't activate the kernel driver until some point in the future.
That's how I see it too. Not security, but developer experience. You set the file as readonly, but provide a message to PostgreSQL superuser that this is as intended
This is discussed in LWN comments, in fact. But the problem there is that the protocol used to communicate the fact that the file is read-only to the application (errno==EACCESS or equivalent on other platforms) does not provide any useful way for the system administrator who makes the file read-only to add a notice explaining why permission is denied, in a way that it is also communicated to the app - so that it could display it to the user.
So the proper solution to this whole thing would be for the OS to provide such a facility: "permission X is denied to Y because Z". This seems like a useful facility in general, come to think of it. But it would have taken more time and effort, and would require buy-in from more parties, some of whom might be very hostile to this notion (e.g. I don't think it would be an easy thing on Linux). No wonder that this isn't an option that is even contemplated as realistic.
And so instead we got yet another easy-to-make crutch in the tower of crutches and duck tape that is modern software.
