Exactly what is wanted with hostfs UID/GID operation
There have been a number of messages dancing around regarding UID/GID/permissions with hostfs.
My original message was that I had a set of patches that fixed bugs with UID/GID mappings when UML is run as "root". If UML is not run as root, then is is impossible to create files in the hostfs area that are not owned by the UML "user" on the host.
The reason for my fixes was that even with UML running as "root" the UID/GID did not always translate down cleanly. My "fix" was basically to enclose all file IO operatoins that could "create" new files or directories inside of seteuid/setegid calls so that UML itself became the user desired during the IO calls. This seems to work well, but again it requires UML run as root.
Some people have talked about other ways to store UID/GID in hostfs. I think this is a completely different thing. My goal was to make the filesystem transparent so that UID/GID were visible and preserved between the host and client access points. Other seem to want some sort of "mapping layer" so that the UML client "sees" UID/GID that follows it, but that the actual host always has a single UID.
From my point of view, there are five options here.
1. Leave the hostfs UID/GID mappings as is (ie. broken). They are good enough to store files and boot from, although some applications seems to complain.
2. Do a patch like I have the keeps the UID/GID "correct" thru to the host assuming that UML is running as root. This is a bit of a security risk for "untrusted" UML situations such as "mass hosting" (which is part of what we do).
3. Do patch #2 so that UML is setuid root. This is a very small amount better in the security department than #2, but still has a lot of
potential "holes".
4. Do patch #2 and build a "helper" process that is root than mangles file ownership externally. This is probably much harder to breach but might be a bit of a performance bottleneck. Implementation wise, it would just be a pair of pipes and an RPC across them to do the actual IO operations.
5. Build a "mapping layer" that stores the UID/GID external to the files themselves. This is what some people are talking about. There are a whole slew of ways to implement this, but I would vote for simplicity and "minimal prerequisites" over performance. A parellel set of directories with text files containing the UID/GID would be one approach. I would vote against anything that requires a formal database setup even though that would outperform other options.
Everything here except for #2/#3 has SMP ramifications. I think that just seteuid/setegid will work SMP pretty much as is in that each thread in SMP can change independently. You have to be careful how you transition down UID/GID structs (statics are bad) but this is probably doable. I am not personally running UML SMP so I don't have a lot of experience here (it is just too convenient to be single-threaded).
I am looking for some discussion here before I start up a formal patch set, so any input would be appreciated.
--------------------------------------------------------------------
Doug Dumitru 800-470-2756 (610-237-2000) EasyCo LLC [email protected] http://easyco.com -------------------------------------------------------------------- D3, U2, jBase Virtual Servers. Off-site backup over the internet. Develop/test/deploy from $20/mo. Fast, secure, cheaper than tape. http://mirroredservers.com http://mirroredbackup.com
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Answering to a previous message of Jeff Dike
Quoted 8 lines · Jeff Dike
Quoted 6 lines · [email protected] said:
The code itself involves a lot of extra parameters from kernel to user
space as things like the current user aren't propogated down. I
personally think that our current patch set is "100% ugly" and would not consider posting it as-is. If people are interested in transparent numeric UID/GID to hostfs, then I would be happy to clean up what we have and submit it.
Quoted 4 lines
OK, that ain't the way to do it. Anything that involves passing a parallel set of creds through VFS will cause Al Viro to lop my head off. Since I'm somewhat attached to it, I will not propose such a thing, no matter how cleaned up it is.
I don't agree. Al Viro doesn't matter here. The only more params to pass are from hostfs_kern.c to hostfs_user.c. Stop. Also, since we are in process context inside hostfs_kern.c, we can also read current very easily (even if we should rely on VFS permission handling as much as possible). By the way, if you want to manage the UMSDOS-like db, then you need to pass exactly the same params down.
**Security risks!**
Besides, even with the UMSDOS-like db, you still need to avoid as much as possible to create root-owned files on the host. It's always a security risk, even if it's not that easy to exploit: for instance, let's look at the man page of modutils:
By default, modutils will reject attempts to use a module that
is not owned by root.
Luckily, you need write access to the /lib/modules path to exploit this, but it's not a good thing anyway. So if we remove this possibility, it's a better world for all us.
Signature · 17 lines
cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN ------------------------------------------------------- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Alle 00:47, martedì 14 ottobre 2003, Doug Dumitru ha scritto:
Quoted 2 lines
There have been a number of messages dancing around regarding UID/GID/permissions with hostfs.
[...] Ok, now I understood very well what you are doing.
Quoted 6 lines
From my point of view, there are five options here.
1. Leave the hostfs UID/GID mappings as is (ie. broken). They are good enough to store files and boot from, although some applications seems to complain.
Not to boot from(there are problems about this+workarounds floating).
Quoted 7 lines
2. Do a patch like I have the keeps the UID/GID "correct" thru to the host assuming that UML is running as root. This is a bit of a security risk for "untrusted" UML situations such as "mass hosting" (which is part of what we do).
3. Do patch #2 so that UML is setuid root. This is a very small amount better in the security department than #2, but still has a lot of
potential "holes".
Do this. But it's not a fix for hostfs that required root UID/GID, it should be rather a fix for when you run it as root. I.e., even if you use option 5, you still need to be careful about permissions on the host. Letting an unpriviledged UML user create a root-owned file on the host is not good. Yes, hostfs isn't something to trust, but anyway making it more secure isn't bad.
But the patch:
1) must not change anything when UML is not run as root
2) when Uml is run as root, it must also change the umask, with that of the current process(at least for open and creat), and also call setgroups(see below).
3) must be clean: i.e. the io calls must be surrounded by functions/inlines/macros, not by the actual calls. I think that it can be done easily "setuid-cleanly". Or better, the more work is for the not-setuid case, where you must set explicitly the saved UID/GID.
4) you speak, for the SMP case, about "static data". This seems to mean you're writing it badly.
Just add some more params to the hostfs_user relevant functions. Or better, to avoid modifying all those params, add(inside hostfs_user) the function which calls sete[ug]id + umask, taking the right params, and then call them from hostfs_kern in the right points(i.e., read, write and close shouldn't need this, but open does, if I'm not missing something great).
5) What's more, once you creat() files with right permissions and IDs, then there shouldn't be the need to do the seteuid calls. This because UML VFS already checked permissions.
6) There is also another issue: supplementary GIDs. I.e. a file with g+w and GID 103, a process with 103 as supplementary group ID, might not be able to open the file with O_WRONLY/O_RDWR if you don't call setgroups, too(open on an existing file shouldn't need the ID changes, see my point 5).
Quoted 7 lines
4. Do patch #2 and build a "helper" process that is root than mangles file ownership externally. This is probably much harder to breach but might be a bit of a performance bottleneck. Implementation wise, it would just be a pair of pipes and an RPC across them to do the actual IO operations.
Wouldn't this have race conditions? I.e. here you have a moment were the file is created and has not get the appropriate permissions. Then, to be atomic inside UML, you'd probably need to lock the whole UML kernel(since any task could try accessing the file) and wait the helper has done its work. So, this isn't very good. And on the host you can try to use that file(while it's owned by root) for an exploit(how to do it, but if a file was created by the admin then it's more trustable).
I agree that it's probably harder to breach than UML running as root, but still weaker than the #5 option.
Quoted 8 lines
5. Build a "mapping layer" that stores the UID/GID external to the files themselves. This is what some people are talking about. There are a whole slew of ways to implement this, but I would vote for simplicity and "minimal prerequisites" over performance. A parellel set of directories with text files containing the UID/GID would be one approach. I would vote against anything that requires a formal database setup even though that would outperform other options.
UMSDOS already exists(but better wait for 2.6 one, since the 2.4 one just uses 8.3 host names). Let they think to performance and then use it.
Quoted 4 lines
Everything here except for #2/#3 has SMP ramifications. I think that just seteuid/setegid will work SMP pretty much as is in that each thread in SMP can change independently.
You have different threads/processes inside UML, but they are mapped on fewer ones on the host. This, with 2.6 preemption, will mean you need to disable preemption on hostfs:
a process could be preempted after having changed id, then a 2nd proc tries to change to another id and maybe get a refusal or looses priviledges, i.e. cannot any more turn back to root id(see the real/effective/file saved ids semantics, I'm not checking here). But then, the 1st process is preempted back and creates the file with the wrong id.
Quoted 11 lines
You have to be careful how you
transition down UID/GID structs (statics are bad) but this is probably doable.
I am not personally running UML SMP so I don't have a lot of experience here (it is just too convenient to be single-threaded).I am looking for some discussion here before I start up a formal patch set, so any input would be appreciated.
--------------------------------------------------------------------
Doug Dumitru 800-470-2756 (610-237-2000)
Bye
Signature · 17 lines
cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel