On Fri, 2007-10-12 at 11:19 -0400, seth vidal wrote: > On Fri, 2007-10-12 at 11:05 -0400, Karl MacMillan wrote: [...] > > > But why prevent it working if you have that infrastructure? Many shops > > want to centralize their identity - both machine and user - so working > > with central identity seems like a huge win. > > actually, that's not true. Many MANAGERS want to centralize their > identity. Most admins want to keep hosts and users as VERY different > concepts. > > Managers want it b/c they think it means they can cut down head count > b/c they'll have fewer pieces to manage. > > > > If a rogue master can spoof the master on the network then your network > > > has very much other problems. > > > Not particularly - it is very easy to do this type of spoofing and > > preventing it is just good protocol design. > > And in the whole scenario you have to get bits onto the minion that you > trust somehow. Your options are: put them in a pkg and trust that the > deployment server is not compromised or spoofed. Which is the same as > the what you're describing above. > > so we've not won anything. We have to have an entry point of trust. > We've chosen ours at the same place puppet chose theirs. > Let me try to push the conversation in a more positive direction. I'm trying to say two things: 1) Your current security mechanisms and implementation present some security risk. You may ultimately decide that the risk is warranted given the benefits - a position I disagree with - but I at least think you should adequately understand and evaluate the risk. 2) I think that adding some access control would make your software _more_ useful not less. This is based on my own experience and users that I talk with. Again, you may determine that adding these features is not what you want to do. So, of course feel free to not act on what I am suggesting, especially as I don't currently have time to contribute. I only mean them as suggestions and feedback about what would make func something that I would be more inclined to use and develop on top of. However, I would suggest that a response of "that is not a use case we won't to solve" would go over a little better than trying to claim that no one is interested in the use case I'm presenting (after all, at least I am interested in it). Thanks - Karl
