#4117 [RFE] Assign a UNIX UID for every principal
Closed: wontfix 5 years ago Opened 10 years ago by jbash.

As far as I can tell at the moment, FreeIPA doesn't assign user IDs for hosts or services. The problem with this is that filesystems, and occasionally other things, uses UIDs for everything. FreeIPA hosts and services aren't "entities" as far as filesystems and the like are concerned.

The immediate problem that prompted this is that I can't create a directory that only a particular host can read or write over NFS4, and in fact I can't really have any protection at all unless I'm willing to leave a keytab lying around that gives out all of some user's access. And there's no reasonable ownership to give to files that really "belong" to a host. In my case, the files are full system backups, and the host really is the most natural owner for them. Anything that root does using a remote service is probably similar.

Similarly, one might want applications to own files or the like. You could do that by assigning UIDs to service principals, and perhaps also letting people put them in groups.

Given the way FreeIPA is set up, "shadow" users for hosts or services aren't really a substitute. What's my host's first or last name, or its car license number?


Given the way FreeIPA is set up, "shadow" users for hosts or services aren't really a substitute. What's my host's first or last name, or its car license number?

Why exactly? You really do not need to fill license number or first and last name for these accounts. It is unclear why creating users for services does not work.
Anyway it seems that you might try to create a special configuration for the managed entry plugin to create a corresponding user entry when service or host entry is created.
Have you tried that path? We would be interested in a solution and publish it on the wiki if you come up with one. As for doing it automatically as part of the project, so far I am not sure we will jump on it. There have been no demand for this so far and there is a good chance that managed entry would help.

I didn't think it was necessary to go into detail on this, because I thought it would be clear.

If you create a shadow user for every host, then you have an extra principal running around to manage. That's a principal that can accidentally get granted access to things, that can have keytabs floating around, and that may not get cleaned up when the underlying host or service goes away. It's a principal that a lot of people and software may assume is an actual user, and give the privileges of a user, because after all the IPA system //says// it's a user.

It's a principal that has to have a defined set of rights, which means there are a bunch of decisions to be made in setting up the whole thing. For example, should this "host user" be able to request certs for the host? Should the email system deliver mail to it, or forward mail for it, or bounce mail for it, and how does that get communicated to the directory and the MTAs? How do I make those things happen? How much am I, as an end user, going to have to learn about the internal structure of FreeIPA, and how much surgery am I going to have to do on FreeIPA and other software to have those "users" treated correctly?

It's also, frankly, an ugly kludge, and my experience has been that those come and bite you, even if you can't predict in advance how they'll bite you. The underlying conceptual framework is that a UNIX UID is a thing to which you assign rights and privileges, and a Kerberos principal is a thing to which you assign rights and privileges. Anything that takes them out of one-to-one correspondence is a place for bugs to creep into the system.

A potential example: as far as I can tell, FreeIPA plugins (which I didn't know existed until now, and which seem to be poorly-if-at-all documented) are for the Web UI. Meaning that any change that happens from the command line can drive the underlying system out of sync with what the plugin expects. Say I delete the host from the command line; now I have a "rogue" principal out there. Or say I //create// the host from the command line, and it doesn't get its user. What breaks? What breaks when I then delete that host from the Web, and the plugin can't delete the corresponding user it thinks should exist?

If one were disciplined to use ONLY the Web UI (which is hard, because it's unscriptable and kind of a pain anyway), then a plugin, assuming it were bug free, might help with the synchronization problem, but it makes the kludge problem worse.

Also, I personally am leery of things like plugins in core infrastructure. From my point of view as a user, FreeIPA already is already pieced together out of way too many complicated moving parts for comfort. Plugins add bugs, and using a plugin means that I either have to be prepared to maintain it myself, or I'm dependent on yet another upstream project... probably a tiny one. And if I ever forget to reinstall it or upgrade it, I can end up hosed. And it's a lot more code exercised for a fairly trivial function.

So maybe it's not important for hosts and applications to be full-fledged UNIX entities, but if it //is// important, I don't think a shadow-user workaround is a good way to achieve it.

By the way, I can't create a user without filling in first and last name, at least not from the Web UI.

Replying to [comment:3 jbash]:

I didn't think it was necessary to go into detail on this, because I thought it would be clear.

If you create a shadow user for every host, then you have an extra principal running around to manage. That's a principal that can accidentally get granted access to things, that can have keytabs floating around, and that may not get cleaned up when the underlying host or service goes away. It's a principal that a lot of people and software may assume is an actual user, and give the privileges of a user, because after all the IPA system //says// it's a user.

It does not matter whether you create a shadow user or treat the same entry as a POSIX entity you will have to deal with the policies and access control.

It's a principal that has to have a defined set of rights, which means there are a bunch of decisions to be made in setting up the whole thing. For example, should this "host user" be able to request certs for the host? Should the email system deliver mail to it, or forward mail for it, or bounce mail for it, and how does that get communicated to the directory and the MTAs? How do I make those things happen? How much am I, as an end user, going to have to learn about the internal structure of FreeIPA, and how much surgery am I going to have to do on FreeIPA and other software to have those "users" treated correctly?

In any case if you make services and hosts have POSIX attributes you would have to deal with policies and access control.

It's also, frankly, an ugly kludge, and my experience has been that those come and bite you, even if you can't predict in advance how they'll bite you. The underlying conceptual framework is that a UNIX UID is a thing to which you assign rights and privileges, and a Kerberos principal is a thing to which you assign rights and privileges. Anything that takes them out of one-to-one correspondence is a place for bugs to creep into the system.

I agree that creating them manually is probably not the best thing as indeed things can get out of sync. But so far it is a workaround that would work without any changes to the code. And so far we have not heard that it is a problem to solve. You claim it is so I am trying to understand how bad the problem is and is it worth fixing and if worth how soon.

A potential example: as far as I can tell, FreeIPA plugins (which I didn't know existed until now, and which seem to be poorly-if-at-all documented) are for the Web UI. Meaning that any change that happens from the command line can drive the underlying system out of sync with what the plugin expects. Say I delete the host from the command line; now I have a "rogue" principal out there. Or say I //create// the host from the command line, and it doesn't get its user. What breaks? What breaks when I then delete that host from the Web, and the plugin can't delete the corresponding user it thinks should exist?

IPA plugins are DS level plugins. UI and CLI use management framework so all the changes are consistent. If you start editing entries with ldapmodify then you might get in trouble if you do not know what you are doing.
As long as you us UI and CLI nothing breaks.

If one were disciplined to use ONLY the Web UI (which is hard, because it's unscriptable and kind of a pain anyway), then a plugin, assuming it were bug free, might help with the synchronization problem, but it makes the kludge problem worse.

Also, I personally am leery of things like plugins in core infrastructure. From my point of view as a user, FreeIPA already is already pieced together out of way too many complicated moving parts for comfort. Plugins add bugs, and using a plugin means that I either have to be prepared to maintain it myself, or I'm dependent on yet another upstream project... probably a tiny one. And if I ever forget to reinstall it or upgrade it, I can end up hosed. And it's a lot more code exercised for a fairly trivial function.

I just suggested you to try and help us to move forward. We do not want you to be the owner and maintainer of a plugin. This does not make sense. What makes sense is to work out a solution that works for you but also for others. Then we would be able to own it. But if you can help would be nice. That would allow for things to move faster for everybody's benefit.

So maybe it's not important for hosts and applications to be full-fledged UNIX entities, but if it //is// important, I don't think a shadow-user workaround is a good way to achieve it.

It is a workaround. That says it all. Next step is crafting a solution. And I proposed to try to look into managed entry plugin. It already exists in IPA and used for couple situations: creating netgroup for every host group and creating a private group for every use. Neither clutter the UI/CLI by show in the ldap lookups from the clients. IMO taking this plugin and adding yet another configuration to create host/service users would be the first step of finding a more "production" level solution you are looking for.

By the way, I can't create a user without filling in first and last name, at least not from the Web UI.

I have not checked but it most likely because of how LDAP standard defines posix user attributes.
But you can emulate fist name and last name by using "host" ad first name and hostname as last name to overcome the issue when configuring the plugin.

You misunderstand the FreeIPA plugin system. The management framework uses the same backend code for the WebUI and the CLI. For the CLI the same code is used on both the server and client.

You raise a good point about shadow users but not every host would require one and it would be fairly straightforward to remove one when removing the other, probably best by by making one a child of the other through the 389-ds managed entries plugin.

Note too that it isn't as easy as assigning a UID. We are constrained by the LDAP and POSIX views of what a user is so certain things need to be defined.

Plugin documentation is available on our wiki, http://www.freeipa.org/page/Documentation#Developer_Documentation

If you are interested in this feature please do a research and POC following the instructions above and create a proposal/design page. We will gladly follow up with you and help with review and implementation.

Metadata Update from @jbash:
- Issue assigned to someone
- Issue set to the milestone: Tickets Deferred

7 years ago

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata