Noux: Implement UNIX passwd functions

[blitz]

Code like getpwuid(getuid()) currently fails in Noux (returns NULL), although it should always work. This is used by popular code (slashem :-) ) without checking for failure. This raises the additional question how the UNIX user db should be handled in Noux in general. Opinions welcome.

[blitz]

(I allow myself a bottle of Club Mate celebrating the 100th issue in Genode's public bug tracker.)

[nfeske]

Hey, congratulations! :-)

Regarding the implementation of user/group-related functionality, I would skip that entirely. I do not envision one Noux instance to be used across multiple users. This would defeat the actualy point of Noux, namely that one user can run many Noux instances, each tailored to a specific use case. Hence, I think we can get away with returning just some predefined structure.

[blitz]

What about the following: Have the default UID something other than 0 (so programs don't believe they run as root) and return a configurable name for the user db-related functions with a sensible default. Sounds reasonably simple to implement and would be useful for e.g. porting Emacs or other programs that might want to know your name.

[blitz]

Just some random notes for myself: The getpwent stuff seems to be deeply tied into the naming services thing in the libc. Bummer... I have to think about that...

[nfeske]

I like you suggestion of optionally supplying the user name via the config file and use fake user db values otherwise. But couldn't we hard-wire the UID simply to 1 on the libc side? Would there by any benefit of handling the UID in Noux?

[blitz]

Maybe when you want to use real unix filesystems. With the current code it should be painfully simple to implement stuff like dropping your rights and become "nobody". That could be useful for network-facing code. It's so simple to properly handle that that I really didn't think about having a fake implementation. ;-)

My current concern is with the name services. I think getprotobyname and friends also use the same magic (nsdispatch) that is used for the user db, so that you can configure lookup via /etc/nsswitch.conf. This is far more flexible than what Noux ever will need. So probably the way to go is to just don't use this stuff at all. Btw, POSIX has really weird interfaces. getpwent is definitely one of them.

On another matter: Norman, do you have an idea to clean up XML handling in user.h? The two helper methods really seem to be something that should be in the generic XML handling code.

[nfeske]

What you said about the use of Unix file systems is exactly what I am concerned about. In my opinion, Genode and Unix access rights are not really compatible with each other. By supporting Unix users/groups (even if its just half way) we set a precedent that would ultimately raise wrong expectations. Supporting Unix file systems with their actual UID/GID scheme is what I want to get over with. Supporting it is not helping my cause. .-)

Maybe I should roughly outline my plans with regard to file system access to make my point a bit clearer. My current idea is to introduce a directory-session interface, to be implemented by file-system implementations. In the simplest case, such a session takes a "path" as constructor argument. For example, if a directory-session clients opens a session, it may specify "/etc" as path. When the session request traverses the Genode tree, each node can modify the path according to its policy. For example, a user-session node may prepend the path with "/users/julian" and hence pass "/users/julian/etc" to the file system implementation. In the same fashion, the UID/GUD as interpreted by the file system can be imprinted into each session individually. But here comes the important point: this imprint is just a policy of the user-session node. There is no need to make UIDs/GUIs visible to Noux at all. It would just dilute the concept.

As long as we can succeed implementing features (such as UID handling) on the libc side w/o Noux needing to be involved, we should go this way and thereby maintain Noux' most important asset, which is its low complexity. Only if there is the pressing need by one of the applications we want to support to add special support into Noux, we should add it. Is this principle reasonable from your point of view?

Regarding the 'try_' helpers, I see the pattern and agree that a generalization of this functionality would be useful. Let my think about it.

[blitz]

In principle you are convincing. In practice, the actual code to support this is so small that it doesn't make a real difference. And in this case, I would go for the correct instead of the fake implementation. I have a feeling that you don't completely get by with ignoring UNIX-style ACLs and user/group IDs, but I have no argument to back that up right now. :) I can live with being proven wrong on this. Mmhh... Maybe sharing your /home between Linux and Genode without destroying information?

Regarding the directory sessions: This sounds a bit Plan9-ish. Do you want to support stacking filesystems on top of each other?

[nfeske]

Please don't take me wrong. I like your code. My gripe is just about my fear that once the code is there, it will be used and may raise wrong expectations. (I made some painful experiences in past with my work on the DOpE windowing system) It will possibly be taken as reference by others who will be misguided to take the wrong turn. In any way it will be impossible or at least hard to cut back the code once it is there. Hence, I am hesitant to include functionality that has no immediate purpose. Maybe we could just keep the patch around so that we can come back to it once we see a concrete need for it?

Regarding the sharing of /home between Linux and Noux, this sounds a bit like opening a can of worms. Personally, I'd prefer to keep that one closed. .-)

About the file-system, indeed, I just learned about the plan9 way during the conversation with Henning at FOSDEM. It looks quite similar to the plan I had in mind. A pity that I am so uninformed about Plan9. Support for stacking file systems would be very useful. My immediate use case is to have multiple tar archives available - one for each GNU package (such as bash, coreutils, gcc, binutils, etc.). For each Noux instance, it should be possible to mount any number of such tar archives together such that their combined content becomes visible as Noux' VFS. I think this would be a pretty handy way to create customized Noux instances.

[nfeske]

User information support has been implemented in a77c3dffd05a904eb67251c731d9168005908ebe