5 ms·
WIN32 got a few things very right: - SIDs - access tokens (like struct cred / cred_t in Unix kernels, but exposed as a first-class type to user-la
by cryptonector 5y ago
WIN32 got a few things very right:
- SIDs
- access tokens
(like struct cred / cred_t in Unix kernels,
but exposed as a first-class type to user-land)
- security descriptors
(like owner + group mode_t + ACL in Unix land,
but as a first-class type)
- HANDLEs, as you say
- HANDLEs for processes
Many other things, Windows got wrong. But the above are far superior to what Unix has to offer.
- al2o3cr 5y agoI'd be curious how many of those derive from NT's VMS roots - for instance: http://lxmi.mi.infn.it/~calcolo/OpenVMS/ssb71/6346/6346p004.htm http://lxmi.mi.infn.it/~calcolo/OpenVMS/ssb71/6346/6346p004....
- cryptonector 5y agoMost of them, as far as I know.
- p_l 5y agoAFAIK WinNT consolidated a lot of ideas from VMS into more coherent constructs, pity that not all of them are exposed to developers (There is, for example, the option of using kernel upcalls in VMS style i.e. ASTs, but it's completely "private" API)
- twoodfin 5y agoI’d add an I/O interface to the kernel that was built to be asynchronous from Day 0.
- cryptonector 5y agoYes! Every system call should take: - an event queue handle for completion notification - an optional event queue handle and timeout for waiting on before returning - the actual arguments to the system call
- lenkite 5y agoYep like Minix does. NO wonder its the world's most popular OS installed everywhere.
- mananaysiempre 5y agoHow are SIDs the right thing? Superficial silliness like allocating 48 bits to encode integers in [0,18] aside, what problem do structured SIDs actually solve? I’ve been trying to figure that out for the last couple of days and I still don’t get it, possibly because the Windows documentation doesn’t seem to actually say it anywhere. I completely agree with having UUIDs or something in that vein for user and group IDs and will not dismiss IDs for sessions and such in the same namespace (although haven’t actually seen a use case for those), but structured variable-length SIDs as NT defines them just don’t make sense to me.
- lukeh 5y agoSIDs are a post-DCE evolution of UUIDs. SIDs differ from UUIDs in that they are hierarchical. In the context of the Windows domain model, they're split into a component which identifies the domain, and a "relative" component which identifies the security principal within the domain. Thus you can easily determine the domain authority to which a principal belongs (useful for filtering across trust boundaries), and you can also efficiently translate between SIDs and human-readable names (you don't need to ask every authority). There is a good paper from Paul Leach which discusses what they learned from using UUIDs in DCE, but I've only ever sighted a paper copy and I don't have access to it anymore...
- cryptonector 5y agoThe hierarchical thing didn't really happen though -- there's no public SID registry. And machine/domain SIDs got pinned to 3 RIDs. So AD always had machine/domain SID conflict issues. It would only ever not have had SID conflict issues if they had had a public SID registry or if you had to install Windows as a domain member rather than install then join (and if there had never been a forest-of-forests feature). Once you accept that machine/domain SID conflicts can happen, the value of having arbitrarily long SIDs goes away and you might as well use UUIDs to ID domains.
- lukeh 5y agoOK, perhaps hierarchical wasn't the correct word; it's not hierarchical in the sense of reflecting a (possibly global) domain hierarchy, but it does consist a component that identifies the issuing authority, and a component that identifies the principal relative to that authority. So yes, a (UUID, RID) tuple would have worked just as well.