At Sun, 30 Apr 2006 20:20:14 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > > 2. I'm not sure how something like 'su fred' would be implemented in > > > this style of system. > > > > You mean as sysadmin without entering a password? No way, unless the > > user grants access to the sysadmin without a password (provided there > > is a mechanism to do so). > > Umm. No. I meant *with* the password. The part I am confused about is > how 'su', which is spawned by me (therefore my child) gains read access > to all of those password files (which is equivalent to read access on > the password database). > > I suspect your answer may be that 'su' is not spawned by me, and that I > have consistently failed to see this. If this is the answer, could you > confirm?
Hm, this is an interesting question. First, authentication can either happen by the system, or done by the user. Both solutions are possible, and the decision which one to use has no further impact on the outcome. Authentication is a bounded operation, so there is no hard resource management problem. You also need a way to advertise the user fred of such a login attempt, but of course you need that anyway. However, the critical question is who implements the virtual terminal that fred uses to attach the session to. If the user who does the "su" implements the virtual terminal that is given to fred's session manager, then fred's session manager makes direct calls to the servers implemented by the user invoking su. This potentially requires a more careful implementation than if a system-implemented terminal is used (recovery boundary?). This is not a fatal problem, it is just something to consider. Fred can have (by several means) reliable information on what type of terminal he is looking at (user implemented or system implemented). If the virtual terminal is always implemented by the system, it may be more reliable, but the system has to provide some shared resource, which is a DoS and resource accounting issue. The Hurdish way would be for the system to stay out of it and just let the users figure it out (of course, with the appropriate default code provided). > > > 3. What happens when the user accidentally deletes their password file? > > > > The user can not login anymore. Which is a good reason for not making > > it a normal file in the first place (among other reasons not to make > > it a normal file), but to have a dedicated service (which can still > > run in the user's space). > > It occurs to me that this may not be what will happen. > > The password "file" is a standalone object with two bindings: one in the > user directory and the other held by the login agent. If the user simply > unbinds their capability, then the situation is that they can still log > in but they can no longer change their password -- this is true because > the login agent has not lost *it's* capability. > > This may still be the right thing, but it is decidedly weird! Ah, you meant "unlink" when you said "delete". I was thinking about "destroy". Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
