Next Previous Contents
<lermen@fgan.de> , Apr 6, 1997

10.1 What we were suffering from

Well, I got sick with the complaints about 'have problems running as user' and did much effort to 'learn' about what we were doing with priv-settings. To make it short: It was a real mess, there was the whole dosemu history of different strategies to reach the same aim. Well, this didn't make it clearer. I appreciate all the efforts that were done by a lot of people in the team to make that damn stuff working, and atleast finding all those places where we need to handle privs was a great work and is yet worth. ... but sorry, how it was handled didn't work.

The main odds happened because sometimes functions, that were called within a priv_on/off()...priv_default() brackets were calling priv_on/off()...priv_default() themselves. And with introduction of this priv_default() macro, which handled the 'default' case (run as user or run as root) the confusion was complete. Conclusion: recursive settings were not handled, and you always had to manually keep track of wether privs were on or off. ... terrible and not maintainable.

Therefore I decided to do it 'the right way (tm)' and overworked it completely. The only thing that now remains to do, is to check for more places where we have to temporary allow/disallow root priviledges. I also decided to be a good boy and make 'RUN_AS_ROOT' a compile time option and 'run as user' the default one.

(promise: I'll also will run dosemu as user before releasing, so that I can see, if something goes wrong with it ;-)

10.2 The new 'priv stuff'

This works as follows

This is much cleaner and 'automagically' also solves the problem with the old 'priv_off/default' sheme. Because, 'running as user' just needs to do _one_ priv_off at start of dosemu, if we don't do it we are 'running as root' ;-)

A last remark: Though it may be desirable to have a non suid root dosemu, this is not possible. Even if we get GGI in the official kernel, we can't solve the problems with port access (which we need for a lot of DOS apps) ... and ioperm() / iopl() need root privileges. This leads to the fact that 'i_am_root' will be always '1', makeing it a macro gives GCC a changes optimize away the checks for it. We will leave 'i_am_root' in, maybe there is some day in the future that gives us a kernel allowing a ports stuff without root privilege, ... never say never ;-)


Next Previous Contents