Fedora considers removing NIS support [LWN.net]

By Jonathan Corbet
October 29, 2021

For all of you youngsters out there, the Internet has always been omnipresent, computers are something you carry in your pocket, the Unix wars are about as relevant as the War of 1812, and the term "NIS" doesn't ring a bell. But, for a certain class of Unix old-timer, NIS has a distinct place in history — and, perhaps, in still-deployed systems. So the suggestion that Fedora might drop support for NIS has proved to be a bit of a wakeup call for some.

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.

to post comments

Fedora considers removing NIS support

Posted Oct 29, 2021 15:57 UTC (Fri) by smoogen (subscriber, #97) [Link] (33 responses)

Years ago I hoped that YP/NIS would be replaced by something as easy to run/slot into networks but with more thoughts about security. I even dabbled with the idea of writing a replacement but even starting off with 'use encryption versus plaintext' turned into a giant case of security corner cases which required more and more 'fixes'. In the end, my work proposal morphed from 5 pages to 40, and was summarized by the the senior Unix admins as "Those who do not understand Kerberos, are condemned to reinvent it, poorly." [Don't worry kid, we have all tried to do one better.]

Fedora considers removing NIS support

Posted Oct 30, 2021 14:02 UTC (Sat) by jezuch (subscriber, #52988) [Link] (28 responses)

Yep, this seems to sum it up nicely. Security is hard, and it's reflected in the way all those better alternatives are not easy to set up. Case in point: encrypted email. The concept is simple, but it reduces to the nightmare of key management. And so email is still not (widely) encrypted.

Fedora considers removing NIS support

Posted Oct 30, 2021 16:35 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (27 responses)

Key management is certainly a problem, but it is nowhere near the only thing wrong with encrypted email. The fact that Signal exists and mostly works is a testament to that. Encrypted email has massive UX* problems, it still doesn't have a widely-accepted encoding format other than chucking ---BEGIN PGP ENCRYPTED MESSAGE--- into a text/plain message (S/MIME doesn't count as "widely-accepted"), support for attachments is somewhere between "it might work" and "it won't work," etc. None of these problems inhere in key management; they are all the results of an unloved, underdeveloped standard that nobody takes seriously.

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?

Fedora considers removing NIS support

Posted Nov 1, 2021 13:45 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (18 responses)

pgp provides web of trust… signal does e2e encryption but unless when you meet you authenticate, there is no authentication.

Fedora considers removing NIS support

Posted Nov 1, 2021 16:08 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (17 responses)

> pgp provides web of trust… signal does e2e encryption but unless when you meet you authenticate, there is no authentication.

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.

Fedora considers removing NIS support

Posted Nov 1, 2021 16:38 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (16 responses)

> Sure, SIM hijacking is a thing... but like I said, Signal "mostly works."

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.

Fedora considers removing NIS support

Posted Nov 1, 2021 18:14 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (15 responses)

To be fair, there is a PIN mechanism. You can't *just* steal somebody's SIM and immediately take over their Signal account. The question is whether users are using good PINs.

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?

Fedora considers removing NIS support

Posted Nov 1, 2021 21:04 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (14 responses)

We are not talking about stealing the SIM, we are talking about doing a man in the middle and registering a signal account without owning the phone number.

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.

Fedora considers removing NIS support

Posted Nov 1, 2021 22:50 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (12 responses)

> We are not talking about stealing the SIM, we are talking about doing a man in the middle and registering a signal account without owning the phone number.

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.
* 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

Posted Nov 2, 2021 7:43 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (10 responses)

> We are not talking about stealing the SIM, we are talking about doing a man in the middle and registering a signal account without owning the phone number.

> 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.
> * Assigning the wrong trust level to someone else's key.

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
* 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).

Those open to a number of attacks by entities in power, that simply PGP doesn't share.

Fedora considers removing NIS support

Posted Nov 3, 2021 0:45 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

> Because users of PGP have human flaws that somehow users of signal don't share…

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.

Fedora considers removing NIS support

Posted Nov 6, 2021 16:27 UTC (Sat) by nix (subscriber, #2304) [Link] (8 responses)

> 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.

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.

Fedora considers removing NIS support

Posted Nov 7, 2021 7:30 UTC (Sun) by LtWorf (subscriber, #124958) [Link] (7 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

This is open to all sort of vulnerabilities.

* replay attack (record voice and form sentences)
* Just imitate the accent (phone calls cut A LOT of frequencies, it's easy to confuse people over the phone)

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.

Fedora considers removing NIS support

Posted Nov 7, 2021 17:34 UTC (Sun) by nix (subscriber, #2304) [Link] (6 responses)

Neither of these work if you actually know the person you're talking to and chat a bit (as people almost invariably do when talking to each other). Shared knowledge will come up almost immediately, and that is going to be unfakeable unless the actual person is there.

Fedora considers removing NIS support

Posted Nov 7, 2021 17:49 UTC (Sun) by LtWorf (subscriber, #124958) [Link] (5 responses)

So you are saying that it is secure in case you are talking to your mother but not in all cases?

People communicate with a number of other people without necessarily being really close on a personal level.

Fedora considers removing NIS support

Posted Nov 8, 2021 0:18 UTC (Mon) by nix (subscriber, #2304) [Link] (4 responses)

Let's step back for a moment. To communicate with people on Signal you have to know their phone number before you can do so. You're saying that you know people's phone numbers without knowing what their voice sounds like?

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.

Fedora considers removing NIS support

Posted Nov 8, 2021 0:34 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

> You're saying that you know people's phone numbers without knowing what their voice sounds like?

In a work-related setting that's perfectly feasible, yes.

Fedora considers removing NIS support

Posted Nov 8, 2021 9:22 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (2 responses)

> To communicate with people on Signal you have to know their phone number before you can do so. You're saying that you know people's phone numbers without knowing what their voice sounds like?

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.

Fedora considers removing NIS support

Posted Nov 9, 2021 17:19 UTC (Tue) by nix (subscriber, #2304) [Link] (1 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.

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.)

Fedora considers removing NIS support

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:

"Ultimate" owner trust binds key trust (how confident you are that the key belongs to the ID that claims it) to owner trust (how much you trust the key owner's introductions).
It uses jargon. "Owner trust" is GPG's term for how confident you are that someone can be trusted to verify that a key and identity match up, "key trust" is GPG's term for how confident the WoT is that the identity and key match. Owner trust has no transitive component - that's entirely set by you based on how confident you are that you can trust a person, while key trust is transitive from owner trust.
When displaying key trust to you, the outcome is binary; either a key is verified, or it isn't. It would be a lot better if you knew how trusted a key was, even though only 100% key trust affects whether or not owner trust comes into play.
There's only three levels of owner trust - by default, 0%, 33% and 100%, although you can tweak in config - which doesn't map well to the way people think about trust.
Related to the above, there's no way to have multiple levels of owner trust for the same person depending on context; for example, in a work context I might have full owner trust in my manager, but in a home context, I might only have limited trust.

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.

Fedora considers removing NIS support

Posted Nov 4, 2021 7:38 UTC (Thu) by madhatter (subscriber, #4665) [Link]

> This is easily defused by simply talking to the other person, once

But that is exactly how people who care about the integrity of their PGP keystore validate new entries therein.

Fedora considers removing NIS support

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:

As an opportunistic thing, to protect messages in transit. This has all the issues that LtWorf describes, because the only validation is the SMS.
As a security thing, where I confirm keys out of band, using the "Verify Security Code" feature to cross-check 12 blocks of 5 decimal digits match between my device and my contact's device. WhatsApp provides a QR code and scanner, so that if I meet face to face with my contact and their device, I can just scan to verify.

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.

Web of trust policy names

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:

I am personally confident that this record is correct via information outside the web of trust. This applies to my key, and to keys I have personally verified to a level I'm happy with offline.
If this record is correct, I am confident that I can trust assertions made by this record. My key should have full trust - I can trust assertions I make - and my confidence in other people is a continuous scale from zero (the assertions made by this record have no impact on my trust) through to 100% (if this record makes an assertion, then I believe it to be true, unconditionally).

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).

Web of trust policy names

Posted Nov 1, 2021 18:19 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (6 responses)

The other UX problem, of course, is that as the length of any PGP-encrypted conversation increases, the probability of somebody accidentally doing a cleartext reply-to-all with a quoted copy of the full, decrypted conversation approaches one.

Web of trust policy names

Posted Nov 1, 2021 19:03 UTC (Mon) by intelfx (subscriber, #130118) [Link] (5 responses)

That's a UX problem of encrypted mail/mail clients, not that of PGP. It seems that the two are being conflated in this discussion.

Web of trust policy names

Posted Nov 1, 2021 19:11 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (4 responses)

Well, yeah. The end user doesn't care which bit is "the standard" and which bit is "the implementation." They care about the product as a whole. Separating them may be useful for technical development, but if you want to assess whether the product is any good, you need to consider it holistically.

Web of trust policy names

Posted Nov 1, 2021 19:27 UTC (Mon) by intelfx (subscriber, #130118) [Link] (3 responses)

No, it's not about the standard vs. the implementation — it's just two completely different pieces of the puzzle (if you replace the encrypted mail clients, the UX problems of web of trust won't go away, and if you replace the web of trust _or_ its implementation with a hypothetical perfect key management system, the UX problems of encrypted mail clients won't go away).

Second, yes, end-users don't care about individual pieces, but for a technical discussion it usually helps to distinguish between unrelated topics.

Web of trust policy names

Posted Nov 1, 2021 20:10 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (2 responses)

> No, it's not about the standard vs. the implementation

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.

Web of trust policy names

Posted Nov 2, 2021 9:16 UTC (Tue) by intelfx (subscriber, #130118) [Link] (1 responses)

> It helps when you're discussing changes to be made.

Yes, exactly, and farnz' subthread was an attempt to do exactly that — which you then derailed by shifting attention to a completely irrelevant issue.

Web of trust policy names

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.

Fedora considers removing NIS support

Posted Oct 30, 2021 14:17 UTC (Sat) by ejr (subscriber, #51652) [Link] (3 responses)

Bonus points for being the only mention of YP so far. ;) Wonder how many of the kiddos know the expansion or the story.

Fedora considers removing NIS support

Posted Nov 1, 2021 12:26 UTC (Mon) by intelfx (subscriber, #130118) [Link] (1 responses)

> Bonus points for being the only mention of YP so far. ;) Wonder how many of the kiddos know the expansion or the story.

I think it's right there in the second paragraph of the article.

Fedora considers removing NIS support

Posted Nov 1, 2021 17:53 UTC (Mon) by ejr (subscriber, #51652) [Link]

Oh, the full name is (so ok,, expansion), but the story certainly is not. Besides, the command names didn't change IIRC. Either way, this was a fun blast from the past as an "ex"-sysadmin.

Fedora considers removing NIS support

Posted Nov 2, 2021 15:04 UTC (Tue) by geert (subscriber, #98403) [Link]

$ yppasswd

Command 'yppasswd' not found, but can be installed with:

sudo apt install nis # version 3.17.1-3build1, or
sudo apt install yp-tools # version 3.3-5.3

Seems like YP did survive. Did the trademarked paper version, too? Here it didn't.

"LDAP isn't light."

Posted Oct 29, 2021 16:53 UTC (Fri) by fmyhr (subscriber, #14803) [Link] (1 responses)

LOL, right up there with "GNU's Not Unix."

"LDAP isn't light."

Posted Oct 31, 2021 6:21 UTC (Sun) by storner (subscriber, #119) [Link]

To be fair, LDAP was light compared to the abomination entitled X.500, which it replaced.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 29, 2021 17:23 UTC (Fri) by faramir (subscriber, #2327) [Link] (19 responses)

I'm one of those old timers who would be annoyed about this change if I actually ran Fedora. I no longer use NIS either, but when I finally
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.

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.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 29, 2021 17:34 UTC (Fri) by nix (subscriber, #2304) [Link] (10 responses)

I'm fairly sure NFS will be supported for a long, long time. Active development on NFSv4.2 continues, and there are lots of installations that use it and manually sync password files (and lots of bigger shops that use it and LDAP for passwd syncing). There is no even remotely tolerable replacement, in my view.

I keep on meaning to try out hesiod...

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 31, 2021 9:40 UTC (Sun) by WolfWings (subscriber, #56790) [Link] (9 responses)

...it's great that NFS v4.whatever is still being developed, but how much is it being USED?

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

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 31, 2021 10:14 UTC (Sun) by nix (subscriber, #2304) [Link] (8 responses)

Well, ignoring weird edge cases like my constant use of it on my home network since 1997 (since I know most people don't turn their home network into a computing cluster), I know that every workplace I've ever worked has used NFS as its sole Unix->Unix shared filesystem protocol (and I've never worked anywhere that didn't use it, a lot.)

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).

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 31, 2021 10:16 UTC (Sun) by nix (subscriber, #2304) [Link] (7 responses)

Oh sorry you were asking how much NFSv4 is being used instead of v3. I suspect that in most cases people using v3 started using v4 without even noticing, because all recent Linux distros will export filesystems as both v3 and v4 by default, and recent Linux distros' NFS clients will try v4 first. So they get the benefit with minimal admin overhead. All that stuff about needing to bind-mount everything into a pseudoroot is completely hidden from you these days: v4 is administered just like v3 was except you don't need to worry about the mountd any more, and file locking works.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 31, 2021 13:26 UTC (Sun) by joib (subscriber, #8541) [Link] (6 responses)

A caveat with v4 is that it requires the passwd &group db's to be available on the NFS server. Be it via NIS, LDAP, in-house shell scripts or whatever. That might convince some admins to go for v3.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 31, 2021 18:28 UTC (Sun) by nix (subscriber, #2304) [Link] (4 responses)

Well, yes. That is of course true of v3 as well: if you don't run the idmapper or Kerberos (and you don't have to), v4 does just like v3 does, and just transports uids and gids blindly. So I don't see how this would encourage adoption of v3 over v4, though it might well encourage adoption of something completely different like SMB or sshfs.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 31, 2021 19:18 UTC (Sun) by joib (subscriber, #8541) [Link] (3 responses)

It does? Oh, that's interesting. Last time I was working with it, without the NSS data the server refused a lot of checks as the user wasn't found and then got remapped to nobody. With v3 you can setup a standalone appliance and never bother with any NSS stuff and it all just works since it never cares to check whether those uid/gid's actually resolve to anything, it just happily trucks along.

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)

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Nov 1, 2021 19:01 UTC (Mon) by bfields (subscriber, #19510) [Link] (2 responses)

Recent NFSv4 server and client will default to using numeric uid's and gid's in stuff like setattrs and getattrs and readdirs, if you're not using krb5.

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/...

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Nov 1, 2021 19:17 UTC (Mon) by joib (subscriber, #8541) [Link] (1 responses)

Ah, thanks, that explains it. Makes sense.

Is this behavior specified in some RFC, or is it a Linux-specific extension?

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Nov 1, 2021 20:12 UTC (Mon) by bfields (subscriber, #19510) [Link]

It's enabled by language that got added to a later version of the RFC (see https://datatracker.ietf.org/doc/html/rfc7530#page-53, starting with "To provide a greater degree of compatibility with NFSv3...").

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.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Nov 1, 2021 1:11 UTC (Mon) by WolfWings (subscriber, #56790) [Link]

Yeah this is the main split I've encountered:

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

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 29, 2021 17:39 UTC (Fri) by amacater (subscriber, #790) [Link]

NFS - depends if you have a long established file system that nobody dares touch with NFS shares throughout which might belong to departed (or, at worst, even dead) co-workers - complex, friagile, ill-understood and yet something vital that's been migrated several times through different attached systems. If someone regards fixing the mess as less important than satisfying the users using it as critical to their daily work - I could see some NFS mounted filesystems lasting for >20 years longer. [Assuming that
someone is around with deep wizard magic and can migrate NFS v3 to v4, maybe even longer still]

The ever excellent xkcd is spot on once again: https://xkcd.com/2531/

Fedora considers removing NIS support (is removing NFS the next step?)

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.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 29, 2021 21:57 UTC (Fri) by Sesse (subscriber, #53779) [Link]

sssd actually makes LDAP/Kerberos fairly smooth. Much, much better than nss_ldap ever was. It feels a bit crazy, but Samba 4 and AD is probably the path of least resistance now, in my experience.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Oct 29, 2021 23:35 UTC (Fri) by dc786 (subscriber, #128390) [Link]

When I also owned Sun computers, I did use NIS and NFS. In a large shared site, NFS would be much harder to run without NIS. Is Network Appliance considering dropping support for NIS?
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.

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
https://ubuntuforums.org/showthread.php?t=1247492

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
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?)

Posted Oct 30, 2021 13:03 UTC (Sat) by cjwatson (subscriber, #7322) [Link]

NFS is used in fairly modern environments that aren't the "everyone's home directory is shared across a whole bunch of machines, so when the NFS server goes down you can't do any work" sort of setup that we knew and hated 20 years ago. For example, nfs-ganesha can export the NFS protocol on top of distributed filesystems like CephFS, and OpenStack Manila uses that sort of thing to provide HA shared filesystem services to VMs.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Nov 1, 2021 2:50 UTC (Mon) by k8to (guest, #15413) [Link] (2 responses)

I tried setting up kerberos at home to learn my way around it.

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.

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Nov 1, 2021 8:25 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

It hasn't. Several years ago I spent a week debugging keytab problems. Turned out that some packages were linked with Heimdal Kerberos implementation that was subtly different from the MIT version. And when both sets of libraries exist on one system, the result is basically "undefined behavior".

Fedora considers removing NIS support (is removing NFS the next step?)

Posted Nov 18, 2021 19:27 UTC (Thu) by kneufeld (guest, #102718) [Link]

I setup FreeIPA with Kerberos in two datacenters with replication across them, and it wasn't easy but it mostly worked. Until it didn't and then it really didn't. FreeIPA/389/OpenLDAP/Kerberos/sssd/WTF-AM-I-EVEN-RUNNING was completely impenetrable. I can't remember but I think the ssl cert expired and I couldn't figure out how to update it.

Long story short I switch to https://github.com/erthink/ReOpenLDAP and it and replication "just works" and is 10x simpler. I recommend.

Fedora considers removing NIS support

Posted Oct 29, 2021 18:42 UTC (Fri) by asn (subscriber, #62311) [Link] (1 responses)

We removed NIS support in Samba with version 4.15.0. The reason is that glibc removed libnsl and rpc headers. So then you needed to look for alternative headers and next or an alternative libnsl (at least with IPv6 support now). When asked on the mailing list if someone is still using or relying on it, nobody answered. Bye bye NIS :-)

Fedora considers removing NIS support

Posted Oct 30, 2021 3:21 UTC (Sat) by pabs (subscriber, #43278) [Link]

Asking on the mailing list if someone uses a feature isn't the way to decide to remove a feature. The people who care about that feature aren't going to be subscribed. A better option would be to make a release that fails to build when you enable NIS and fails to run when NIS is enabled, unless special "I have contacted the samba team and requested NIS to remain supported" options are enabled at both build and run time.

NIS+

Posted Oct 29, 2021 20:08 UTC (Fri) by pwfxq (subscriber, #84695) [Link]

At my old job we migrated from NIS to NIS+. We regretted it. Even Sun admitted that it wasn't great and advised us to either roll back to NIS or migrate to LDAP. I didn't recall it being that hard to switch LDAP.

I also vaguely recall that NIS+ supported the notion of a hierachy to enable it to scale better.

Fedora considers removing NIS support

Posted Oct 29, 2021 21:50 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

A big problem with NIS is that necessarily each node has access to the (hashed) passwords. NIS provides attackers with the same hashes that you'd be outraged to hear were stolen from, say, Facebook or (heaven forfend) LWN - as a feature of its simplicity.

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.

Fedora considers removing NIS support

Posted Nov 1, 2021 11:45 UTC (Mon) by njh (subscriber, #4425) [Link] (1 responses)

I don't work in a NIS environment any longer, but at my previous role I used to use NIS as a lightweight distribution mechanism for harmonised passwd and group maps across all the hosts in an environment, but *without* the password hashes in passwd.

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.

Fedora considers removing NIS support

Posted Nov 6, 2021 14:28 UTC (Sat) by nix (subscriber, #2304) [Link]

This is, of course, what Hesiod was invented for by the same people who came up with Kerberos. I don't understand why it's not more widely used, particularly now DNSSEC is a thing. All you want is a distributed database, after all, and that's exactly what DNS is...

Fedora considers removing NIS support

Posted Oct 29, 2021 22:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

LDAP and Kerberos barely work in the classic setup, too-many-s-d makes it more palatable but it's still not good.

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.

Fedora considers removing NIS support

Posted Oct 30, 2021 2:34 UTC (Sat) by jhoblitt (subscriber, #77733) [Link] (5 responses)

If anyone gets access to the machine they have the signed host cert and then some how *can't* impersonate the host? I guess if that makes them feel better. 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.

Fedora considers removing NIS support

Posted Oct 30, 2021 2:37 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> If anyone gets access to the machine they have the signed host cert and then some how *can't* impersonate the host?

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.

Fedora considers removing NIS support

Posted Oct 30, 2021 22:04 UTC (Sat) by jhoblitt (subscriber, #77733) [Link] (3 responses)

If you break into a host configured as a freeipa client, or standard krb5 client, the only secret accessible is the host's keytab (and potentially cached TGTs of users). This does not provide the ability to create new principals on the KDC or impersonate the KDC. It also doesn't provide a secret that can be used to decrypt the communication between the KDC and any other kr5b client as the host key is used as an initial shared secret to then setup a session key. It is a completely valid criticism to say that there is no option of perfect forward secrecy for client<->KDC communication and compromising a host's keytab could allow decryption of its historical communication with the KDC from packet capture. I suspect some environments would still choose to use the existing shared secret scheme instead of paying the cost overhead of public key exchange but it would be nice if was an option.

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

Fedora considers removing NIS support

Posted Oct 30, 2021 22:23 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

As far as I understand, if you can access the keytab for the machine, then you can impersonate the KDC for that machine. As far as I remember, there's no way to authenticate the KDC in that case. And you can use that to sniff users' credentials later.

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.

Fedora considers removing NIS support

Posted Oct 31, 2021 1:13 UTC (Sun) by rra (subscriber, #99804) [Link]

This is correct, but if you can access the keytab for the machine, in most situations that means you have root access to that machine anyway, so I'm not sure there's a lot of weight-bearing security space left. (I suppose, technically speaking, you have read access to a file that in theory is only readable by root, and it's not immediately trivial to turn that into full root access, but I wouldn't want to rely on that.)

Fedora considers removing NIS support

Posted Nov 1, 2021 16:03 UTC (Mon) by abo (subscriber, #77288) [Link]

"impersonate the KDC" is not how I'd put it (more like "impersonate the host"), but yes if you have access to the keytab for a host (and you can redirect IP traffic to your machine) then you can do everything the real host can do, including receiving ssh connections, over which the user then may send other secrets such as their passwords or their forwarded personal keys.

It's not really that different from having access to a regular SSH server's private host keys.

Fedora considers removing NIS support

Posted Oct 30, 2021 2:38 UTC (Sat) by jhoblitt (subscriber, #77733) [Link]

Having run both NIS and freeipa with hundreds of hosts and users in an academic environment (freeipa decades later)... My option is that about NIS is kill it with fire. The implementations we're often buggy. About the only nice thing I can same about it is you could do a lot of debugging with with tcpdump (nobody used NIS+).

Fedora considers removing NIS support

Posted Oct 30, 2021 11:31 UTC (Sat) by josh (subscriber, #17465) [Link] (1 responses)

I wonder how difficult it would be to provide a completely separate daemon that transforms NIS into synthetic passwd/group/shadow files via FUSE, and then mount that over /etc/passwd and /etc/group and /etc/shadow at boot time? That would completely remove the need for special integration with authentication.

(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.)

Fedora considers removing NIS support

Posted Oct 30, 2021 13:47 UTC (Sat) by cbcbcb (subscriber, #10350) [Link]

The problem seems to be that NIS support is mixed in with other authentication methods.

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.

Fedora considers removing NIS support

Posted Oct 31, 2021 22:23 UTC (Sun) by wtarreau (subscriber, #51152) [Link]

Amusing. I didn't notice it was still supported. I probably haven't met NIS for 20 years now. And I'm known for using old stuff! :-)

Fedora considers removing NIS support

Posted Nov 1, 2021 8:04 UTC (Mon) by jengelh (subscriber, #33263) [Link] (2 responses)

LDAP could just be even more "L"-lightweight: Ditch the OID mappings, ditch the ASN.1/LBER encoding. For what it's worth, ldapsearch output and ldapmodify input is just shy of being JSON already (just missing some quotes and curly braces).

Fedora considers removing NIS support

Posted Nov 1, 2021 21:05 UTC (Mon) by lamikr (subscriber, #2289) [Link] (1 responses)

How easy and what kind of steps are actually needed for the Linux client machines so that they would use LDAP authentication on home network? And how does this work in case where your Linux laptop is not connected to home network or your ldap home server is down. Is there some kind of fail on mechanism to use the /etc/passwd or some kind of ldap cache in those cases?

Fedora considers removing NIS support

Posted Nov 1, 2021 22:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> How easy and what kind of steps are actually needed for the Linux client machines so that they would use LDAP authentication on home network?

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.

Fedora considers removing NIS support

Posted Nov 2, 2021 20:36 UTC (Tue) by ken (subscriber, #625) [Link]

As long as there is some replacement that is easy to use.

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.