root password

[Bernardo Innocenti]

Albert Cahalan wrote:

> I got it to work with a different pam module, and placed
> that info into trac. http://dev.laptop.org/ticket/5537
>
> #%PAM-1.0
> auth      sufficient  pam_rootok.so
> auth      required    pam_succeed_if.so use_uid user ingroup wheel
> auth      include     system-auth
> account   sufficient  pam_succeed_if.so uid = 0 use_uid quiet
> account   include     system-auth
> password  include     system-auth
> session   include     system-auth
> session   optional    pam_xauth.so

This seems really equivalent to using pam_wheel.so.

I think we should put your change as yet another pilgrim
hack (rather than branching coreutils to edit /etc/pam.d/su).

> This is an excellent idea. Doing tty1 through tty6 would
> be good.

Using just 2 shells was a way to save some memory.  Kids will
use none.  Whoever needs more can easily edit /etc/inittab.


> I strongly feel that:
> 
> if sudo works
> then su must work

Thumbs up.

Moreover, I strongly feel that /sbin and /usr/sbin are the
creation of the devil and serve no other purpose than irritating
unprivileged users when they want to call ifconfig or mount.
It also interacts especially badly with "sudo -s" and "su".

Therefore, I've just added /usr/local/sbin:/usr/sbin:/sbin to
the user path.


> Note that the above does not require sudo to work. It doesn't
> even require su to work, given that sudo doesn't work.

Good point, but if we left just that in place, we'd have to
ask people to use the ugly text console more often, where the
keyboard works partially and there's no cut & paste.

Ideally, one would rather try to make the system work so well
that there would be no need to use that ever.  See MacOSX.


> I don't believe there is any real need to protect the root
> account from the olpc account.

There is: the Browse activity still runs as olpc because it
is hard to containerize.  But one could argue that there's
not that much of a difference between compromising olpc and
compromising root on a single-user machine.


> If there is, then a root login
> should require the SAK key. (Alt-Ctrl-SysRq by default)
> This is the only way to be sure that one is not typing into
> a trojan. Maybe Fn-Esc makes a good SAK key.

I wonder how it plays with setxkbmap and loadkeys.

<offtopic>
 <msbashing>
  On Windows, they tell users that CTRL-ALT-DEL is a proected
  system sequence that no application can ever intercept, but
  it's just a gross lie.  On Windows 2000, you can edit the
  registry as a user to remap keys to other keys, including
  all of CTRL, ALT and DEL.

  I know because I wanted to remap CAPS-LOCK to CTRL and I did
  by mistake the other way around, so I couldn't login any
  more through MSGINA :-)
 </msbashing>
</offtopic>

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/