See 6.2.1 of RFC8881, where NFSv4 ACLs are described. They are quite similar to Windows ACLs.
Here is kernel dev telling they are against adding NFSv4 ACL implementation. The relevant RichAcls patch never got merged: https://lkml.org/lkml/2016/3/15/52
My only experience with non-UAC endpoint privilege management was BeyondTrust and it seemed to try to do what UAC did but with a worse user experience. It looks like the Intune EPM offering also doesn't present as clear a delineation as UAC, which seems like a missed opportunity.
> The pictures are alarming; we should include them. But what does the analysis add?
The analysis shows another way in which the government is trying to be secretive about how it's treating people that were within its borders and subject to its laws and protections. I can only hope someone pointed this out because the question suggests a baffling level of ignorance despite the message overall sounding like some reasonable feedback on the story, despite coming far too late in the process to be considered reasonable.
Since it’s all classified o honestly don’t have a clue. But passive radar is also a thing and something that the Swedish defense industry is fairly good at https://en.wikipedia.org/wiki/Passive_radar.
It probably has more to do with the fact that solar that far north is a non-starter. Any PV installed there will actually make AGW and carbon emissions worse, not better. Basically, the amount of carbon emitted due to manufacturing is greater than the carbon savings over the lifetime of the panel in those locations.
That makes sense but my first thoughts were that panels wouldn't be oriented so that the majority of that flat surface was perpendicular to the radar but instead much closer to parallel, and that aviation radar would be higher up than a house roof to avoid ground clutter.
The 5us inaccuracy is basically irrelevant to NTP users, from the second update to the Internet Time Service mailing list[1]:
To put a deviation of a few microseconds in context, the NIST time scale usually performs about five thousand times better than this at the nanosecond scale by composing a special statistical average of many clocks. Such precision is important for scientific applications, telecommunications, critical infrastructure, and integrity monitoring of positioning systems. But this precision is not achievable with time transfer over the public Internet; uncertainties on the order of 1 millisecond (one thousandth of one second) are more typical due to asymmetry and fluctuations in packet delay.
> Such precision is important for scientific applications, telecommunications, critical infrastructure, and integrity monitoring of positioning systems. But this precision is not achievable with time transfer over the public Internet
How do those other applications obtain the precise value they need without encountering the Internet issue?
> If those other applications use their own local GPS clocks, what is the significance of NIST (and the 5μs inaccuracy) in their scenario?
Verification and traceability is one reason: it's all very well to claim you're with-in ±x seconds, but your logs may have to say how close you are to the 'legal reality' that is the official time of NIST.
NIST may also send out time via 'private fibre' for certain purposes:
That is not correct at all. How did you arrive at that conclusion?
GPS has its own independent timescale called GPS Time. GPS Time is generated and maintained by Atomic clocks onboard the GPS satellites (cesium and rubidium).
It has its own timescale, but that still traces back to NIST.
In particular, the atomic clocks on board the GPS satellites are not sufficient to maintain a time standard because of relativistic variations and Doppler effects, both of which can be corrected, but only if the exact orbit is known to within exceeding tight tolerances. Those orbital elements are created by reference to NIST. Essentially, the satellite motions are computed using inverse GPS and then we use normal GPS based on those values.
I think GP might’ve been referring to the part of Jeff’s post that references GPS, which I think may be a slight misunderstanding of the NIST email (saying “people using NIST + GPS for time transfer failed over to other sites” rather than “GPS failed over to another site”).
The GPS satellite clocks are steered to the US Naval Observatory’s UTC as opposed to NIST’s, and GPS fails over to the USNO’s Alternate Master Clock [0] in Colorado.
I find this stuff really interesting, so if anyone's curious, here's a few more tidbits:
GPS system time is currently 18s ahead of UTC since it doesn't take UTC's leap seconds into account [0]
This (old) paper from USNO [1] goes into more detail about how GPS time is related to USNO's realization of UTC, as well as talking a bit about how TAI is determined (in hindsight! - by collecting data from clocks around the world and then processing it).
Yes, either Rb, Cs, or H standards depending on which GNSS system you're using.
For the most critical applications, you can license a system like Fugro AtomiChron that provides enhanced GNSS timing down to the level of a few nanoseconds. There are a couple of products that do similar things, all based on providing better ephemerides than your receiver can obtain from the satellites themselves.
That's one hell of a healthy profit margin there O.o
The SiTime MEMS oscillator is about 100€ for one single chip, the mosaic-T GPS receiver is about 400€. Add 50€ for the rest (particularly the power input section looks complicated) and 50€ for handling, probably 600€ in hardware cost... sold for 2.500€.
The real money I think went into certification and R&D for a low-volume product - even though most of the hard work is done by the two ICs, getting everything orchestrated (including the PCB itself) to perform to that level of accuracy is one hell of a workload.
Yep, for hardware sold in low volumes, what looks like a healthy or even abusive profit margin turns out to be barely adequate to justify getting out of bed in the morning.
There are so many artificial bureaucratic barriers to entry these days, and it's not getting better.
A lot of organizations also colocate timing equipment near the actual clocks, and then have 'dark fiber' between their equipment and the main clock signals.
Then they disperse and use the time as needed.
According to jrronimo, they even had one place splice fiber direct between machines because couplers were causing problems! [1]
If I put my machine near the main clock signal, I have one clock signal to read from. The comment above was asking about how to average across many different clocks, presumably all in different places in the globe? Unless there's one physical location with all of the ones you're averaging, you're close to one and far from all the others so how is it done without the internet?
Can you do PTP over the internet? I have only seen it in internal environments. GPS is probably the best solution for external users to get time signals with sub-µs uncertainties.
I think it fails to be objective because of the repetition. It's an open S3 bucket. No need to state that no authentication was required, it's already open. It's not about economy of writing but the repetition emphasizes the point, elevating the perceived significance to the author or that the author wants the reader to take away.
Furthermore, the repeated use of every when discussing the breadth of access seems like it would easily fall into the "absolutes are absolutely wrong" way of thinking. At least without some careful auditing it seems like another narrative flourish to marvel at this treasure trove (candy store) of firmware images that has been left without adequate protection. But it seems like most here agree that such protection is without merit, so why does it warrant this emphasis? I'm only left with the possible thought that the author considered it significant.
An 'open S3 bucket' sounds really bad. If it were posted on an HTTPS site without authentication, like the firmware for most devices, it wouldn't sound so bad.
Sure an open bucket is bad, if it's stuff you weren't planning on sharing with the whole world anyway.
Since firmware is supposed to be accessible to users worldwide, making it easier to get it is good.
But how is an open, read-only S3 bucket worse than a read-only HTTPS site hosting exactly the same data?
The only thing I can see is that it is much easier to make it writeable by accident (for HTTPS web site or API, you need quite some implementation effort).
Full blown production SPAs are served straight from public access S3 buckets. The only hard requirement is that the S3 bucket enforces read-only access through HTTPS. That's it.
Let's flip it the other way around and make it a thought experiment: what requirement do you think you're fulfilling by enforcing any sort of access restriction?
When you feel compelled to shit on a design trait, the very least you should do is spend a couple of minutes thinking about what problem it solves and what are the constraints.
No I agree with you. I think it is bad framing as "S3 open bucket" when people would totally understand an open website :)
I'm not shitting on anything except the wording in the article.
I guess I didn't word it clearly.
In our company we don't really serve directly from open buckets but through cloudfront. Though this is more because we are afraid of buckets marked open by mistake so they are generally not allowed. But I agree there's nothing bad about it. I just meant it sounds much worse (at least to someone in cybersec like me) and I don't like the effect used as such in the article.
My ready example of a GitLab pain point is parallel matrix job names include the matrix variables and quite easily, in complex configurations, exceed the static 255 character limit of job names, preventing job creation/execution.
There's been years of discussion about ways to fix it with nothing moving forward.
reply