Fedora considers removing NIS support
NIS ("Network Information Service") was initially born in the depths of Sun Microsystems as "Yellow Pages". It came about in those heady times when Unix workstations were beginning to pop up in offices — and were being connected to just-installed 10Mb/s Ethernet networks via a (suitably named for the Halloween season) vampire tap. Having a network made it possible to copy around various administrative files like /etc/passwd and create an early sort of single-sign-on regime on the local network. We were all quite proud of ourselves for setting such things up.
As the number of systems grew, though, all of that copying became a little cumbersome and machines easily went out of sync. Yellow Pages was Sun's way of automating this work within a simple, centralized service. Getting a network running with it was a quick process, and adding new clients was even faster. There were occasional problems, of course, leading to the system being renamed "Yellow Plague" by some users, but as a whole, it worked quite well. That is for a value of "quite well" that discounts its total lack of access control, encryption, or defenses against malicious hosts masquerading as servers, but that was a more innocent age.
Sun eventually ran into trademark problems with the Yellow Pages name; being a Unix company, Sun had a deep understanding of the folly of getting into legal battles with telecommunications companies, so it wisely changed the name to NIS. The later NIS+ release added some security and reliability features but looked similar in many ways. Eventually, though, Sun lost interest in NIS (and just about everything else) and the system fell from its nearly dominant position in Unix shops into obscurity. It would be surprising indeed to see a new deployment adopt it now.
Linux systems still carry support for NIS, though. The pam_unix authentication module supports it, and distributions still package the various NIS utilities. At the beginning of October, though, Björn Esser suggested that Fedora, at least, might stop doing so soon. Esser is working on a project to replace pam_unix (which also receives little attention anymore) with a simpler alternative; one of the things that would make it simpler would be to drop support for NIS. He wanted to know if anybody was still actively using it.
It seems that users do still exist; they were perhaps most aptly described by Stephen John Smoogen:
The places I have seen it still being used are in Universities run by people who learned sysadmin in the 1990's and early 2000's. It is a light weight system which is simple to set up and tends to be the goto-stick for a lot of 'we put this together in 1999 with RHL6 and upgraded ever since' places.
There may be more examples of that kind of site than anybody expects. Frank
Ch. Eigler was quick to
ask
whether any simple alternatives exist. The answer would appear to be
"no". Smoogen responded
that: "There is LDAP but that isn't light. There are kerberos but
that isn't easy
". But, he added, an awful lot of the "cool
kids
"
just defer to one of the large service providers for authentication
services — a solution that seems unlikely to appeal to anybody who has
made the effort to keep NIS running for all of these years.
One relatively easy alternative that does exist, as pointed
out by Tomasz Torcz, is FreeIPA. But, as Smoogen
noted,
it still is not as easy to manage as NIS and will be a hard sell for NIS shops:
"Most of the site admins running NIS I know would change their text
editor to $that_other_one before they would turn off NIS
". Even so,
he said that the time has come to stop using and supporting it.
The removal of NIS support was posted
as a Fedora 36 goal on October 21. Eigler then asked for the
provision of some scripts to help sites migrate to something else; that
request has gone unanswered so far.
The change proposal does note that:
"For some users this change may be a bit disruptive and it may
require some learning curve for switching to alternative solutions
".
Fedora project leader Matthew Miller responded to
that statement by saying: "I've spoken with some of my sysadmin
friends and universities, and they suggest that the above is enough of an
understatement to feel insulting
". He suggested that
Fedora 36, which is currently aiming for a release in April, might be
too soon for this change.
Given that nothing is calling for the urgent removal of NIS, that
suggestion seems likely to be heeded. But the end of NIS support in Fedora
is clearly in the works, and it will likely come sooner than some users
would like. It's worth noting that RHEL 9 will not
support NIS either. The Yellow Pages/NIS system has had a good run
over the decades, but it would appear that the time has come to run from
it.
Posted Oct 29, 2021 15:57 UTC (Fri)
by smoogen (subscriber, #97)
[Link] (33 responses)
Posted Oct 30, 2021 14:02 UTC (Sat)
by jezuch (subscriber, #52988)
[Link] (28 responses)
Posted Oct 30, 2021 16:35 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (27 responses)
Yes, key management and distribution is a hard problem, possibly the hardest problem in all of applied cryptography. But it is far from intractable, and it's also far from the only thing you have to get right.
* Quick, what's the difference between "full" trust and "ultimate" trust? Do you really think the average user is equipped to answer that question?
Posted Nov 1, 2021 13:45 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (18 responses)
Posted Nov 1, 2021 16:08 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (17 responses)
Users already know each others' phone numbers. Sure, SIM hijacking is a thing... but like I said, Signal "mostly works." Regardless, your claim that PGP provides a "web of trust" is grossly exaggerated since the average user has never heard of a "key-signing party" and would not know how to get linked into said web of trust, so it might as well not exist at all, for all intents and purposes.
Posted Nov 1, 2021 16:38 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (16 responses)
Well according to this logic, also clear text http mostly works.
How often does it actually happen that someone does a man in the middle?
Security is not designed with the idea that nobody will attack you. Because as we have seen, attacks do happen. To some more than others.
If people haven't had key signing parties, then they get out of PGP the same security they get out of Signal.
Posted Nov 1, 2021 18:14 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (15 responses)
But the exact same criticism applies to PGP - Are users actually setting sane passphrases? Are they properly sequestering their keying material? Or are they chucking an unlocked private key directly into Dropbox or something?
Posted Nov 1, 2021 21:04 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (14 responses)
For example someone registers a signal/whatsapp/telegram account using my phone number, gets the confirmation SMS from one of the many well known SMS attacks. At this point people on signal who have my phone number will think that is me.
And that's why signal gives you no authentication, while PGP does.
We are not talking about hitting people with a wrench… of course if someone steals my phone and guesses the PIN, they can do whatever they want on signal. But they can impersonate me without having to ever meet me in person.
> Or are they chucking an unlocked private key directly into Dropbox or something?
Come on… if your security model is that the PGP user is an idiot while the signal user is smart, you are modelling wrong.
Posted Nov 1, 2021 22:50 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (12 responses)
This is easily defused by simply talking to the other person, once, and telling them whether or not you use Signal with phone number X. From there, trust is permanently bootstrapped, at least for as long as you can keep the phone number. In the US and probably other jurisdictions, the phone number belongs to the consumer, so that you can keep it indefinitely even when you change phone companies.
Is that less efficient than a web of trust? Yeah, probably. But in practice, most end users talk to each other (in person or via something like Zoom) much more frequently than they attend key-signing parties, so this efficiency difference is completely overwhelmed by the cold, hard reality of end user behavior.
> Come on… if your security model is that the PGP user is an idiot while the signal user is smart, you are modelling wrong.
The model is that both the PGP user and the Signal user can make mistakes, to the extent that the system allows them to make mistakes. The only mistakes you can make under Signal are setting a bad PIN or believing the other person's identity without independently confirming that they are in fact using Signal. Those are real problems; I never claimed that Signal is perfect. OTOH, there are numerous mistakes you can make with PGP:
* Poor key storage.
Posted Nov 2, 2021 7:43 UTC (Tue)
by LtWorf (subscriber, #124958)
[Link] (10 responses)
> This is easily defused by simply talking to the other person, once,
Not once… the attack can happen at any moment and so for people who don't use signal, their newly created signal account must be ignored until the meeting in person can happen.
> Is that less efficient than a web of trust? Yeah, probably. But in practice, most end users talk to each other (in person or via something like Zoom) much more frequently than they attend key-signing parties
Depends if they live in the same area or not, and the web of trust has the concept of transitory trust, so you don't need to meet everyone you write emails to. With your schema you need to meet and have the authenticating conversation with every single person you interact with.
You don't NEED a key signing party… you can just sign the key of 1 single person when you meet in person. So basically just your protocol but better because of transitive trust.
But people who use signal do not wait until they can meet in person to write to each other, and until they meet and explicitly ask about signal, their communication is e2e encrypted with a potential complete stranger.
> so this efficiency difference is completely overwhelmed by the cold, hard reality of end user behavior.
So, for signal, this means completely unauthenticated, like I keep telling you…
But you keep re-inventing a bad version of PGP and and think that somehow your-pgp-over-signal will work better than actual PGP… if PGP didn't work your protocol will fail too.
> The only mistakes you can make under Signal are setting a bad PIN or believing the other person's identity without independently confirming that they are in fact using Signal.
The PIN is your red herring. As I said, SMS can be hijacked without the PIN…
> * Poor key storage.
Plugging your phone to an unknown charger can expose you to an attack where your keys are stolen.
> * Sending a cleartext reply-to-all.
??? PGP supports fully well encrypting the same message for multiple recipients.
> * Signing a key without seeing adequate evidence of its owner's identity.
As opposed to no verification whatsoever on signal?
> * And so on...
Ok you decided, for no logical reason, that signal is more secure than PGP. Because users of PGP have human flaws that somehow users of signal don't share…
Signal has a number of problems:
* centralised
Those open to a number of attacks by entities in power, that simply PGP doesn't share.
Posted Nov 3, 2021 0:45 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
Please do not put words in my mouth. I explicitly described all of these bullets as mistakes which PGP enables the user to make, not as vulnerabilities in PGP itself. I also acknowledged that Signal users are capable of making mistakes as well, a sentence which you even quoted, and then proceeded to accuse me of neglecting to mention the second mistake (of two) which I mentioned ("believing the other person's identity without independently confirming that they are in fact using Signal").
You have an agenda. That's fine. But I don't, so I'm going to respectfully disengage at this time.
Posted Nov 6, 2021 16:27 UTC (Sat)
by nix (subscriber, #2304)
[Link] (8 responses)
Meeting in person? You don't need to meet in person: you just need to know what your interlocutor's voice sounds like and call them on the phone number you probably already have for them, or, if you don't, their claimed phone number on Signal (not a Signal call, an ordinary phone call). You then ask them whether they're using Signal, and (unless coerced, in which case all bets are off anyway) you then know whether or not to trust the Signal number.
These are trivial properties of trustworthiness which any human being who uses phones at all easily understands. My 76-year-old mother would understand them instantly. The requirements you have to satisfy to use PGP safely? I'm not sure *I* know them properly and I've been using PGP (reluctantly) for decades: I do know you have to get them right *every time* and if you mess up one message that's it.
This is much worse and much more fragile than Signal's one-off easily-understood check.
Posted Nov 7, 2021 7:30 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (7 responses)
This is open to all sort of vulnerabilities.
* replay attack (record voice and form sentences)
As you can see, it works fine in the case where we don't need security and presume nobody is attacking. Not so fine if we presume someone is actually attacking.
Posted Nov 7, 2021 17:34 UTC (Sun)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Nov 7, 2021 17:49 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (5 responses)
People communicate with a number of other people without necessarily being really close on a personal level.
Posted Nov 8, 2021 0:18 UTC (Mon)
by nix (subscriber, #2304)
[Link] (4 responses)
I mean, yes, this is still not ideal -- it discriminates against deaf people, for starters. But it's a hell of a lot better than the thoroughly untrustworthy web of trust, which neither covers enough people to have any chance of actually reaching anyone but a tiny fraction of techies, nor fails safe, nor is easy enough to use that you're going to be able to use it without at the very least worrying about accidentally committing disastrous security fubars, nor even has a sane model of trust -- trust among human beings is *not* transitive at all, just because I trust my mother does not in any sense mean that I trust any of her friends, and just because she distrusts, say, her brother doesn't mean that I distrust him. Partly this is just bad terminology, but that just means that you're asking people to decide about "trust" when the thing you're actually asking them about isn't particularly related to anything like trust at all, but a *new concept* that every single person who sends and receives secure encrypted messages using PGP has to keep in mind more or less at all times. No *wonder* it tanked.
Posted Nov 8, 2021 0:34 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
In a work-related setting that's perfectly feasible, yes.
Posted Nov 8, 2021 9:22 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Well you can exchange numbers on dating apps, for work, you can post ads with your phone to sell your old couch, and as I said the phone audio quality is not nearly the same as real world audio.
> neither covers enough people to have any chance of actually reaching anyone but a tiny fraction of techies
Well whatever app you use will only work if the other person has the same app.
> trust among human beings is *not* transitive at all, just because I trust my mother does not in any sense mean that I trust any of her friends, and just because she distrusts, say, her brother doesn't mean that I distrust him.
Luckily PGP lets you express how much a person's trust can be trusted!
How much you trust a key and how much you trust signatures done with that key are separate concepts.
> No *wonder* it tanked.
And yet… at work I need a PGP key to sign every commit, as part of security policy.
Posted Nov 9, 2021 17:19 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
Sure! But in all these cases these are people you don't actually know at all. Surely in that case the trustworthiness of the communication is kinda irrelevant? The relevant point is the one you knew before you started: this is a number that connects to someone you don't know, and you have no actual reason to trust that the phone number is the number you think it is. No PGP-style web of trust would help here either because *you don't know this person*: the PGP web of trust's trust should be zero (though thanks to the lunacy that is transitive trust, if the web was wide enough it might *not* be zero, entirely falsely) and the Signal web of trust tells you "I trust that this person owns this phone number" -- but you still don't trust the phone number! And this is mostly something that human beings in the real world are familiar with: though mistakes in this area do happen and are the foundation of a lot of social engineering attacks, many of which are as old as the telephone and at least some of which have been in existence for as long as the mail (e.g. who wrote the letter which exposed the Gunpowder Plot? Some speculate that it might have been Robert Cecil, the then Secretary of State... that's the exact same attack, in the early 17th century.)
And this idea (a phone number which claims in the place you found it to be e.g. a work number but is actually someone else's) is a social engineering problem which cannot possibly be fixed by any sort of technical solution below a hypothetical reliable global identity service (and then you have to worry about the people who run that service). No such service exists, nor likely can it in the absence of a trustworthy world government.
(I don't think the security of Signal or PGP in re determining the trustworthiness of your communicants is likely to be relevant with regard to selling your old couch. You don't need to trust those people to do anything but give you money and turn up and take your couch away, and if they don't do the one they don't get the other. You don't *need* to trust them or know who they are.)
Posted Nov 9, 2021 19:35 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
A Web of Trust (WoT) doesn't have transitive trust by default; owner trust is set by you, and not imported from the key servers (ever).
If you don't trust anyone else's assertions about a link between an identity and a key, then you do not give anyone other than yourself owner trust. You end up with key trust only existing for keys that you've verified yourself.
In practice, this isn't how identity works in human interaction - you trust not only identities that you've verified yourself, but also identities that other people give you in an introduction. A published signature from me on someone else's key is the WoT equivalent of me being willing to introduce this person under this identity to anyone I know; you can decide how much introductions from me are worth (owner trust), and that will lead into the WoT algorithms deciding whether you'd be willing to trust a key based on who's willing to introduce you to the owner of that key.
Now, the GPG implementation of the WoT has a lot of UX problems, which mean that it gets into a bad state - but that's not WoT style, that's GPG's implementation:
In terms of the jargon, if I were willing to put the work in to fix WoT issues, I'd make "owner trust" the only form of trust; "key trust" would become "verification". Then, keys that are fully verified would have their owner trust used to help verify more keys; trust remains something that you only set manually.
Posted Nov 4, 2021 7:38 UTC (Thu)
by madhatter (subscriber, #4665)
[Link]
But that is exactly how people who care about the integrity of their PGP keystore validate new entries therein.
Posted Nov 2, 2021 10:39 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
At least with WhatsApp (I've not used Signal, but it's the same underlying protocol, so the only issue is whether Signal has a UI at least as good as WhatsApp's UI for security), there are two ways for me to treat the encryption:
To support the second option, WhatsApp puts notifications in chat of the form "Your security code with ${contact} changed. Tap to learn more" when the other end changes key. If I tap that, I have a "Verify Code" button, which brings me back to cross-checking 12 blocks of 5 decimal digits with my contact.
I can then make an informed decision about how I treat my contact; if the security is not something I care about for this conversation, I can ignore it (option 1 again). If I do care, I can keep communicating, but I treat my contact as compromised until I can reverify codes.
Posted Nov 1, 2021 17:20 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (7 responses)
Disclaimer: I believe that "web of trust" could be made to work with a good UX on top, so I'm not unbiased here.
The gap between full and ultimate trust in a key is about whether the key is a root of your web of trust. A key with ultimate trust is a root key in the web of trust - you trust keys it signs, even if it isn't verified by the web of trust. A key with full trust needs to be verified by the web of trust before you trust keys it signs.
The UX issue here is that we're trying to bring trust from outside the web of trust so that we can pretend that the web of trust is all that exists. Out in the real world, we have two separate statements we want to make:
GPG instead forces you to express both of these things via a single trust value, where "ultimate" is the special case that you are personally confident that the record is correct outside the web of trust, and that you can trust assertions made by this record 100% without needing corroboration. This is in part because, once you're doing this, it's easy to publish your confidence in a record to the key servers, enabling a global web of trust to exist.
Personally, I think this conflation is a mistake; while it means that GPG gets to do everything via the web of trust algorithm, it makes it very hard to explain things to end users - as your question demonstrates (it shouldn't even be a question you can ask).
Posted Nov 1, 2021 18:19 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Posted Nov 1, 2021 19:03 UTC (Mon)
by intelfx (subscriber, #130118)
[Link] (5 responses)
Posted Nov 1, 2021 19:11 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
Posted Nov 1, 2021 19:27 UTC (Mon)
by intelfx (subscriber, #130118)
[Link] (3 responses)
Second, yes, end-users don't care about individual pieces, but for a technical discussion it usually helps to distinguish between unrelated topics.
Posted Nov 1, 2021 20:10 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
Fine, break it into whichever pieces you like. It's irrelevant.
> but for a technical discussion it usually helps to distinguish between unrelated topics.
Yes and no. It helps when you're discussing changes to be made. It does not help when you're trying to understand the overall user experience of a product and how it compares to other products, such as Signal. The entire ecosystem of "encrypted email," as a whole, is grossly inferior to products like Signal, even allowing for some theoretical differences in their respective threat models. And it's never going to get better, unless people are willing to accept that reality and work to change it. Breaking the problem space apart into a bunch of different pieces and saying "not my problem, it's that other piece that's terrible!" is entirely unhelpful.
In other words: Pieces, such as GPG, Enigmail, Thunderbird, etc. do not have their own individual UX's. There is only the holistic UX of their combination. That is what users actually experience, and therefore that is what we must care about, if we're to care about UX at all.
Posted Nov 2, 2021 9:16 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Yes, exactly, and farnz' subthread was an attempt to do exactly that — which you then derailed by shifting attention to a completely irrelevant issue.
Posted Nov 2, 2021 10:37 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
My comment was a response to NYKevin's throwaway remark about one way in which encrypted e-mail implemented as an GPG overlay on unencrypted mail has bad UX. I chose to expand on his point about bad UX by explaining first what it's trying to do, and next why this is bad UX and how I'd fix it for a web of trust.
It's not unreasonable, in that context, to then move onto other bad UX patterns in encrypted e-mail as implemented.
Posted Oct 30, 2021 14:17 UTC (Sat)
by ejr (subscriber, #51652)
[Link] (3 responses)
Posted Nov 1, 2021 12:26 UTC (Mon)
by intelfx (subscriber, #130118)
[Link] (1 responses)
I think it's right there in the second paragraph of the article.
Posted Nov 1, 2021 17:53 UTC (Mon)
by ejr (subscriber, #51652)
[Link]
Posted Nov 2, 2021 15:04 UTC (Tue)
by geert (subscriber, #98403)
[Link]
Command 'yppasswd' not found, but can be installed with:
sudo apt install nis # version 3.17.1-3build1, or
Seems like YP did survive. Did the trademarked paper version, too? Here it didn't.
Posted Oct 29, 2021 16:53 UTC (Fri)
by fmyhr (subscriber, #14803)
[Link] (1 responses)
Posted Oct 31, 2021 6:21 UTC (Sun)
by storner (subscriber, #119)
[Link]
Posted Oct 29, 2021 17:23 UTC (Fri)
by faramir (subscriber, #2327)
[Link] (19 responses)
This does, however, make me wonder how much longer NFS will continue to be supported. I no longer work in the trenches and wonder to what extent it is being used for new installations now that there are so many new, cooler (and distributed!) network filesystems.
Posted Oct 29, 2021 17:34 UTC (Fri)
by nix (subscriber, #2304)
[Link] (10 responses)
I keep on meaning to try out hesiod...
Posted Oct 31, 2021 9:40 UTC (Sun)
by WolfWings (subscriber, #56790)
[Link] (9 responses)
Over the last 15 years I've seen less than 10 NFS deployments that weren't NFS v3; and even today there's storage arrays that only support NFS v3 but not v4.anything.
And I don't just mean the small stuff either, there's heckin' ENORMOUS petabyte-range arrays being sold that flip the entire bird at NFS v4 support. :S
Posted Oct 31, 2021 10:14 UTC (Sun)
by nix (subscriber, #2304)
[Link] (8 responses)
This is certainly not zero usage. Yes, enormous petabyte-scale arrays aren't going to use it because honestly when you're at *that* scale you have a variety of huge specialized cluster filesystems instead. That's not what NFS is targetted for (at least, not these days).
Posted Oct 31, 2021 10:16 UTC (Sun)
by nix (subscriber, #2304)
[Link] (7 responses)
Posted Oct 31, 2021 13:26 UTC (Sun)
by joib (subscriber, #8541)
[Link] (6 responses)
Posted Oct 31, 2021 18:28 UTC (Sun)
by nix (subscriber, #2304)
[Link] (4 responses)
Posted Oct 31, 2021 19:18 UTC (Sun)
by joib (subscriber, #8541)
[Link] (3 responses)
And yeah, sure, if you need Kerberos, then you're gonna need the server be joined to the domain and have NSS and all that jazz.
(A factor in favor of NFSv4 is that as of v4.2(?) the leases and compound mechanisms have been enhanced to the point they can actually substantially reduce roundtrips compared to v3, which wasn't really possible in practice with v4.0)
Posted Nov 1, 2021 19:01 UTC (Mon)
by bfields (subscriber, #19510)
[Link] (2 responses)
There's a little explanation of this in the documentation of the nfs.nfs4_disable_idmapping and nfsd.nfs4_disable_idmapping parameters in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
Posted Nov 1, 2021 19:17 UTC (Mon)
by joib (subscriber, #8541)
[Link] (1 responses)
Is this behavior specified in some RFC, or is it a Linux-specific extension?
Posted Nov 1, 2021 20:12 UTC (Mon)
by bfields (subscriber, #19510)
[Link]
But of course that doesn't require anyone to update their implementation. I'm not sure what the deal is with non-Linux clients and servers.
Posted Nov 1, 2021 1:11 UTC (Mon)
by WolfWings (subscriber, #56790)
[Link]
Broad network of servers that don't actually use a centralized unified ID system for users, and generally just need to share a given folder among 2-30 web-nodes to avoid having as many points of failure as a 'primary + replicas' approach.
It's all on private internal networks, mounted on boot, and just a shared storage volume across, often using the 02775 type configuration locking everything into a manually created GID for relatively crude permissions.
Like sure, that's light-years away from best or even sane practice, but that describes a HUGE swath of active storefronts at this point since it's the easiest way to scale out a lot of CMS installs that don't natively support horizontal scaling. Stuff the NFSv3 on a private internal network and go. And as a result that's what a fair number of storage vendors offer on the NFS side for some reason. O.o
Posted Oct 29, 2021 17:39 UTC (Fri)
by amacater (subscriber, #790)
[Link]
The ever excellent xkcd is spot on once again: https://xkcd.com/2531/
Posted Oct 29, 2021 19:44 UTC (Fri)
by adam820 (subscriber, #101353)
[Link]
According to this comment on the article about Tesla vehicles, it's used by the on-board computers. The job I left recently used quite a bit of NFS between client and server for file storage. NFS is also used quite a bit as a network backing store for VMWare servers. There's enough use case for it that it's still provided as an add-on for Windows Server. I think NFS will be around a long time.
Posted Oct 29, 2021 21:57 UTC (Fri)
by Sesse (subscriber, #53779)
[Link]
Posted Oct 29, 2021 23:35 UTC (Fri)
by dc786 (subscriber, #128390)
[Link]
I searched for a comparison of NIS and Microsoft's Active Directory, and found a comment that one site used Novell's SLES for something they considered a superset of both at
But, NIS is not just for passwd (users), group, and a few admin domains that LDAP, Hesiod or Kerberos might handle. I never did get any of those three to work, by the way. I tried quite a bit, more than once, with LDAP. I did use some NIS non-default maps to set up mounting user home directories from numerous filesystem partitions that a large site requires via what Sun called automount.
Here are the 25 default maps for NIS (I used
Posted Oct 30, 2021 13:03 UTC (Sat)
by cjwatson (subscriber, #7322)
[Link]
Posted Nov 1, 2021 2:50 UTC (Mon)
by k8to (guest, #15413)
[Link] (2 responses)
After source code diving to try to figure out the 8th completely incomprehensible set of errors and after manually debugging the 3rd problem that gave nothing actionable at all, I decided that the kerberos software available was not ready for use by humans.
I sure hope it got better.
Posted Nov 1, 2021 8:25 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 18, 2021 19:27 UTC (Thu)
by kneufeld (guest, #102718)
[Link]
Long story short I switch to https://github.com/erthink/ReOpenLDAP and it and replication "just works" and is 10x simpler. I recommend.
Posted Oct 29, 2021 18:42 UTC (Fri)
by asn (subscriber, #62311)
[Link] (1 responses)
Posted Oct 30, 2021 3:21 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
Posted Oct 29, 2021 20:08 UTC (Fri)
by pwfxq (subscriber, #84695)
[Link]
I also vaguely recall that NIS+ supported the notion of a hierachy to enable it to scale better.
Posted Oct 29, 2021 21:50 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
Now, if every user has great passwords, and your nodes are all running some reasonably modern OS this is fine. There's enough potential entropy that "cracking" those hashes just isn't viable if the least secure password in the system is say 16 random alphanumerics. But, if some of your users don't have great passwords (perhaps even don't have *good* passwords) or you're on NIS because of that tired old machine still doing Unix crypt, you're in a world of pain.
Posted Nov 1, 2021 11:45 UTC (Mon)
by njh (subscriber, #4425)
[Link] (1 responses)
Instead of storing valid password hashes in NIS, I used pam_krb5 to do password authentication and TGT fetching from the University's centralised Kerberos infrastructure. So presence of the username in my NIS map was effectively authorisation for the account holder to use workstations in the domain, but I devolved authentication to a Kerberos setup that was already maintained by someone else in the organisation.
When creating a new user account I just matched the newly created username in the NIS passwd map to the already centrally allocated single-sign-on username, and made an NFS home directory. There were no sensitive data or password hashes in the NIS maps, only mappings of "this uid and gids belong with this username", so the fact that anyone on the LAN could get a copy of the information wasn't too problematic, and I had the clients bind to the NIS master and redundant replica servers by server IP address, so things were not trivially disruptable by a rogue or hostile NIS server (in the way that a classic 1980s Sun NIS architecture using broadcasts can be).
It was simple, robust, it meant that users didn't have yet-another-username-and-password to remember, and it got me out of the irksome tasks of validating users and setting/resetting/sunsetting passwords because I was leveraging the fact that someone else in the organisation was already doing those identity management things.
Posted Nov 6, 2021 14:28 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Oct 29, 2021 22:50 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
One problem with Kerberos is that it uses symmetric crypto, so if somebody gets access to machine keys, they can impersonate the server and there's a host of other attacks. I know a company that attempted to add CA infrastructure via a custom Kerberos implementation, it worked but never acceptably well.
In the end, they went with a script that uses CURL with certificate-based authentication to get /etc/passwd, /etc/sudoers.d and synchronize home directories and their authorized_keys. It worked much better than the tower of straw built on top of LDAP and Kerberos.
Posted Oct 30, 2021 2:34 UTC (Sat)
by jhoblitt (subscriber, #77733)
[Link] (5 responses)
Posted Oct 30, 2021 2:37 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
You can impersonate the host, but you can't impersonate the server (because machines don't have the server's CA). This also allows secure authentication, because there can't be man-in-the-middle.
> It is actually a bit more of a pain to distribute a crl in the x509 model then to invalidate a hosts ticket under krb5 because of the centralized model.
Uhm... OCSP helps with that. And in a corporate environment it's easy to set up and guarantee its usability. There's also no problem with CURL working over public Internet.
Posted Oct 30, 2021 22:04 UTC (Sat)
by jhoblitt (subscriber, #77733)
[Link] (3 responses)
It isn't clear to me if sssd has support for OCSP stapling. This is the only really relevant hit I can turn up: https://github.com/SSSD/sssd/issues/4907
Posted Oct 30, 2021 22:23 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
With asymmetric keys you'd be able to put a non-secret public key on machines so that they can always verify that they're talking to the real KDC.
Posted Oct 31, 2021 1:13 UTC (Sun)
by rra (subscriber, #99804)
[Link]
Posted Nov 1, 2021 16:03 UTC (Mon)
by abo (subscriber, #77288)
[Link]
It's not really that different from having access to a regular SSH server's private host keys.
Posted Oct 30, 2021 2:38 UTC (Sat)
by jhoblitt (subscriber, #77733)
[Link]
Posted Oct 30, 2021 11:31 UTC (Sat)
by josh (subscriber, #17465)
[Link] (1 responses)
(You'd still need to use a separate tool like yppasswd to handle password/information changes, as well, unless you want to make that filesystem writable and try to interpret local writes. Probably safer to make the file read-only.)
Posted Oct 30, 2021 13:47 UTC (Sat)
by cbcbcb (subscriber, #10350)
[Link]
NIS could be supported by a separate PAM module, which could be done cleanly and wouldn't impose a maintenance cost on people aren't involved with it.
Posted Oct 31, 2021 22:23 UTC (Sun)
by wtarreau (subscriber, #51152)
[Link]
Posted Nov 1, 2021 8:04 UTC (Mon)
by jengelh (guest, #33263)
[Link] (2 responses)
Posted Nov 1, 2021 21:05 UTC (Mon)
by lamikr (guest, #2289)
[Link] (1 responses)
Posted Nov 1, 2021 22:03 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Pretty hard. You can do it for fun and education if you're inclined.
> And how does this work in case where your Linux laptop is not connected to home network or your ldap home server is down.
Classic LDAP and Kerberos basically don't work at all in this scenario. However, more modern sssd-based stack will work.
Posted Nov 2, 2021 20:36 UTC (Tue)
by ken (subscriber, #625)
[Link]
I use it just for my two computers and handful of virtual machines. but I use also the autofs/nfs mounting stuff so its just not only the password for the user that needs replacement if NIS is removed.
So when I need to create a new virtual machine I just turn NIS on on the new machine and all the disk and user accounts is the same. well depending on what netgroup I put the machine in.
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
* Sending a cleartext reply-to-all.
* Signing a key without seeing adequate evidence of its owner's identity.
* Assigning the wrong trust level to someone else's key.
* And so on...
Fedora considers removing NIS support
> * Assigning the wrong trust level to someone else's key.
* updates pushed by google/apple store
* needs a phone number
* no reproducible builds (so you don't know if what you get from google is the same stuff that you get compiling it).
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
* Just imitate the accent (phone calls cut A LOT of frequencies, it's easy to confuse people over the phone)
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
sudo apt install yp-tools # version 3.3-5.3
"LDAP isn't light."
"LDAP isn't light."
Fedora considers removing NIS support (is removing NFS the next step?)
stopped, it wasn't because I changed to LDAP or Kerberos. For my use case: small number of systems with single admin and small number of users who mostly only ever logged into one of them, it was easier to manually add users to each system and periodically sync password files than to switch to LDAP/Kerberos. Maybe it's gotten easier, but LDAP and Kerberos were just way too much work. I wasn't running a federated environment with distinct areas of control and potentially untrusted systems. If I was going to redo it now, I might do something involving passwordless SSH keys and only allow direct password logins to a user's primary system.
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
someone is around with deep wizard magic and can migrate NFS v3 to v4, maybe even longer still]
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Have they already? NIS is a major contributor to productivity of sysadmins. But my computers are only running Linux, OpenBSD, Windows 7 or 8.1 or Android these days. There are only about 10 of them and they don't have much need for sharing files or administration. Only 4 are in daily use. But I'm retired.
https://ubuntuforums.org/showthread.php?t=1247492
https://docs.oracle.com/cd/E19683-01/817-4843/anis1-24268... to find these):
bootparams
ethers.byaddr
ethers.byname
group.bygid
group.byname
hosts.byaddr
hosts.byname
mail.aliases
mail.byaddr
netgroup.byhost
netgroup.byuser
netgroup
netid.byname
netmasks.byaddr
networks.byaddr
networks.byname
passwd.adjunct.byname
passwd.byname
passwd.byuid
protocols.byname
protocols.bynumber
rpc.bynumber
services.byname
services.byservice
ypservers
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support (is removing NFS the next step?)
Fedora considers removing NIS support
Fedora considers removing NIS support
NIS+
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support