[9fans] First-timer help

[9fans] First-timer help

[John Floren]

Hi.
I just installed Plan 9 on an old machine, and I'm having a bit of 
trouble.  I am used to Linux, so any comparisons you might make to Linux 
should make sense to me.
First, I installed Plan 9 from CD with the fossil file system.  It 
installed just fine; when I rebooted, I chose to login as "glenda" and 
came up with a nice screen.  Now I want to add some other users, but I 
haven't had much luck.  I tried "con /srv/fscons" and then typing "uname 
john john", then quitting.  I then ran "auth/changeuser john" and tried 
to set my password, but I got a "permission denied" error.  Help?
I am also a bit confused about how to login/logout.  Do you have to 
reboot every time you want to change users?
Thanks

John F.
-- 
http://nuwen.net/~digi/cluster
Be sure to evaluate the bird-hand/bush ratio.

Re: [9fans] First-timer help

[Gorka guardiola]

http://www.cs.bell-labs.com/wiki/plan9/Adding_a_new_user/

After, when you log in for the first time run
/sys/lib/newuser

look at the wiki (url above) for this kind of information.

On 7/17/05, John Floren <jfloren@moseslake-wa.com> wrote:
> Hi.
> I just installed Plan 9 on an old machine, and I'm having a bit of
> trouble.  I am used to Linux, so any comparisons you might make to Linux
> should make sense to me.
> First, I installed Plan 9 from CD with the fossil file system.  It
> installed just fine; when I rebooted, I chose to login as "glenda" and
> came up with a nice screen.  Now I want to add some other users, but I
> haven't had much luck.  I tried "con /srv/fscons" and then typing "uname
> john john", then quitting.  I then ran "auth/changeuser john" and tried
> to set my password, but I got a "permission denied" error.  Help?
> I am also a bit confused about how to login/logout.  Do you have to
> reboot every time you want to change users?
> Thanks
> 
> John F.
> --
> http://nuwen.net/~digi/cluster
> Be sure to evaluate the bird-hand/bush ratio.
> 


-- 
- curiosity sKilled the cat

Re: [9fans] First-timer help

[John Floren]

Gorka guardiola wrote:
> http://www.cs.bell-labs.com/wiki/plan9/Adding_a_new_user/
> 
> After, when you log in for the first time run
> /sys/lib/newuser
> 
> look at the wiki (url above) for this kind of information.
I've already read through the wiki.  I did run newuser after I manager 
to login as my new user.  However, I still cannot set any passwords, so 
logging in is kinda insecure.
And why do you have to reboot in order to change users?  UNIX has had 
that from the beginning, and I don't see any reason to drop it.
Thanks

> On 7/17/05, John Floren <jfloren@moseslake-wa.com> wrote:
> 
>>Hi.
>>I just installed Plan 9 on an old machine, and I'm having a bit of
>>trouble.  I am used to Linux, so any comparisons you might make to Linux
>>should make sense to me.
>>First, I installed Plan 9 from CD with the fossil file system.  It
>>installed just fine; when I rebooted, I chose to login as "glenda" and
>>came up with a nice screen.  Now I want to add some other users, but I
>>haven't had much luck.  I tried "con /srv/fscons" and then typing "uname
>>john john", then quitting.  I then ran "auth/changeuser john" and tried
>>to set my password, but I got a "permission denied" error.  Help?
>>I am also a bit confused about how to login/logout.  Do you have to
>>reboot every time you want to change users?
>>Thanks
>>
>>John F.
>>--
>>http://nuwen.net/~digi/cluster
>>Be sure to evaluate the bird-hand/bush ratio.
>>
> 
> 
> 


-- 
http://nuwen.net/~digi/cluster
<knghtbrd> He's a about half the size of the others.
<knghtbrd> But he's got a chainsaw.

Re: [9fans] First-timer help

[Russ Cox]

> I've already read through the wiki.  I did run newuser after I manager
> to login as my new user.  However, I still cannot set any passwords, so
> logging in is kinda insecure.
> And why do you have to reboot in order to change users?  UNIX has had
> that from the beginning, and I don't see any reason to drop it.

You're not using the system the way it was intended.  In a full-blown
Plan 9 setup there is a file server and a cpu server, and users each
sit at their own terminals.  To change users, you reboot the terminal,
but any long-running stuff on the cpu server doesn't go away just
because one terminal rebooted.

Rebooting has been easy enough, so we haven't bothered to put
more complexity into the system to make changing users easier.

Russ

Re: [9fans] First-timer help

[Charles Forsyth]

>>Rebooting has been easy enough, so we haven't bothered to put
>>more complexity into the system to make changing users easier.

also if you are certain you've rebooted (eg, little reset button
or perhaps power cycle) there's much less chance that preceding
person using the same terminal has left something lurking
(such as a fake login screen for instance, which UNIX has had
almost from the beginning)

Re: [9fans] First-timer help

[Martin C. Atkins]

On Mon, 18 Jul 2005 00:12:44 +0100 Charles Forsyth <forsyth@terzarima.net> wrote:
> >>Rebooting has been easy enough, so we haven't bothered to put
> >>more complexity into the system to make changing users easier.
> 
> also if you are certain you've rebooted (eg, little reset button
> or perhaps power cycle) there's much less chance that preceding
> person using the same terminal has left something lurking
> (such as a fake login screen for instance, which UNIX has had
> almost from the beginning)

I understand, and in many situations agree with, all the
arguments for re-booting to change users.

Nevertheless, I must add that this is one reason why I haven't
installed Plan9 on my systems at home - there are more people than
computers here, and I can't lose all my context (of active windows,
etc), when my wife needs to check her email, or my daughter wants to
paint a picture....

There are environments where you can be reasonably sure that a trojan
hasn't been installed (and security amoungst the people with physical
access isn't that important either), but where you really do want to
be able to change your identity/context without re-booting. Linux
virtual consoles are a great solution (although not 100% reliable, in
my experience).

Martin

-- 
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] First-timer help

[lucio]

> Nevertheless, I must add that this is one reason why I haven't
> installed Plan9 on my systems at home - there are more people than
> computers here, and I can't lose all my context (of active windows,
> etc), when my wife needs to check her email, or my daughter wants to
> paint a picture....

I was thinking, when Russ suggested that the infrastructure for
changing ID without rebooting was a possibility, that we'd lose the
extreme reliability of the current approach.  That need not be true,
either, as the reboot option is unlikely to go away.

That said, a stand-alone Plan 9 device seems to need better
specification, I'm sure a CPU server is perfectly capable of sharing
its console to different users at different times.  But different
logins on different windows (as Martin seems to suggest) would be more
complicated.  I guess somebody ought to give the idea some careful
thought and suggest an implementation.  Specially where we actually
want the stand-alone device to be more of a workstation than a CPU
server, yet we need local authentication and device management.

++L

Re: [9fans] First-timer help

[Jack Johnson]

On 7/18/05, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > computers here, and I can't lose all my context (of active windows,
> > etc), when my wife needs to check her email, or my daughter wants to
> > paint a picture....
> 
> complicated.  I guess somebody ought to give the idea some careful
> thought and suggest an implementation.  Specially where we actually
> want the stand-alone device to be more of a workstation than a CPU
> server, yet we need local authentication and device management.

It's interesting to consider this specific problem, where you want to
keep your context but allow someone else momentary use of your
workstation.

If cpu and auth servers are available, I wonder if it would suffice to
lock most of the local resources and fire up another copy of rio in
someone else's context?  My brain can't wrap around how you might
swing that at the moment, but I'm picturing something that's half
screensaver (to keep the guest from accessing local windows/namespace)
and half drawterm that doesn't export the local terminal's filesystem.
 The guest would still be susceptible to someone replacing the
'guestterm' binary, but you could have some sort of reasonable
expectation that the guest could access the cpu server securely and
still keep your session/data/namespace intact.

You would probably want to re-authenticate after closing the guestterm.

Feel free to poke more holes in my Swiss cheese.

-Jack

Re: [9fans] First-timer help

[Martin C. Atkins]

On Mon, 18 Jul 2005 12:45:32 +0200 lucio@proxima.alt.za wrote:
> > Nevertheless, I must add that this is one reason why I haven't
> > installed Plan9 on my systems at home - there are more people than
> > computers here, and I can't lose all my context (of active windows,
> > etc), when my wife needs to check her email, or my daughter wants to
> > paint a picture....
> 
> I was thinking, when Russ suggested that the infrastructure for
> changing ID without rebooting was a possibility, that we'd lose the
> extreme reliability of the current approach.  That need not be true,
> either, as the reboot option is unlikely to go away.

The other approach, that might "just happen" without specific
development effort in Plan 9, is that if/when Xen provides graphical
screens for virtual machines, then it should be possible to run a
cpu/file server, and a terminal for each user, each on their own
virtual screen, switching between them somewhat like virtual
consoles. (Of course, in principle, I could do that today with
Vmware, if I had enough memory, etc.)

[Of course, this would mean that everything would have to be running
on top of Linux/whatever...]

> That said, a stand-alone Plan 9 device seems to need better
> specification, I'm sure a CPU server is perfectly capable of sharing
> its console to different users at different times.  But different
> logins on different windows (as Martin seems to suggest) would be more
> complicated.  I guess somebody ought to give the idea some careful
> thought and suggest an implementation.  Specially where we actually
> want the stand-alone device to be more of a workstation than a CPU
> server, yet we need local authentication and device management.

Agreed.

Allowing some form of su (as was suggested elsewhere) is very useful,
but isn't really an answer to my problem. Also the
drawterm-on-top-of-a screensaver idea (while a nice bit of lateral
thinking!) also wouldn't be very satisfactory, because the reverse
problem then occurs: we lose the context in the drawterm when going
back to the underneath "original" session (and how would it nest
further?). 

Again (I'm sorry to say): Linux virtual consoles work very well,
since all the logins are "at the same level". One can also screenlock
a session, and let someone use another virtual console, reasonably
sure that they can't fiddle with your session. (assuming the other
security mechanisms are working 'correctly')

BTW: This problem is even more acute when travelling, and we only want
to carry one laptop as a family, and carry it around with all our
personal sessions suspended.

This is the counter example for Bill Gates' infamous "your computer
should be as personal as your underwear" gaff - unfortunately, this
seems to be the philosophy for Plan 9 terminals, currently. big :-)

[Although I should reiterate that I think the situation can be quite
different in other environments - such as offices and terminal
classrooms - where rebooting makes lots of sense.]

Moving to solutions, rather than problem statements: wouldn't the
"Plan 9 way" of dealing with this be to run a multiplexer process
pre-login, that multiplexes access to /dev/draw(etc) across several
virtual consoles, and puts a login process in each one? Could that be
done with the current mechanisms? I guess it would have worked with 8
1/2, but maybe it is more difficult with the rio approach (I don't
know)? I also don't know if this is consistent with the way /dev/user
(etc) work. Comments anyone?

Martin
-- 
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] First-timer help

[Axel Belinfante]

> Allowing some form of su (as was suggested elsewhere) is very useful,
> but isn't really an answer to my problem. Also the
> drawterm-on-top-of-a screensaver idea (while a nice bit of lateral
> thinking!) also wouldn't be very satisfactory, because the reverse
> problem then occurs: we lose the context in the drawterm when going
> back to the underneath "original" session (and how would it nest
> further?). 

not a plan 9 way, but could using vnc make a difference here?
(or something similar)
I tend to have a long-running 'persistent' vnc session on a server
at work, and pick up (connect to) the session whereever I am.

Axel.

Re: [9fans] First-timer help

[Ronald G. Minnich]

On Tue, 19 Jul 2005, Martin C. Atkins wrote:

> [Of course, this would mean that everything would have to be running
> on top of Linux/whatever...]

unless/until we do a Xen dom0 for plan 9, which in fact would not be that 
hard.

ron

Re: [9fans] First-timer help

[Martin C. Atkins]

On Tue, 19 Jul 2005 07:57:17 -0600 (MDT) "Ronald G. Minnich" <rminnich@lanl.gov> wrote:
> On Tue, 19 Jul 2005, Martin C. Atkins wrote:
> > [Of course, this would mean that everything would have to be running
> > on top of Linux/whatever...]
> 
> unless/until we do a Xen dom0 for plan 9, which in fact would not be that 
> hard.
> 
> ron

Now *that* would be very interesting - not just for this discussion,
but also for completely unrelated reasons (are you reading this Wes?).

Martin

-- 
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] First-timer help

[Charles Forsyth]

using VM/386 to multiplex window sessions is rather like virtualising the
Unix system call layer to allow several IP stacks.  it seems just
a little heavy-handed.  there is actually little difference between
multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned:
mainly configuration and a few small policy differences.

if each user is given a rio session, much as martin suggested,
and it has its own name space (as with newns)
it will use its own attach to the file server, and
thus run with the desired file permissions.

/dev/user can be set using cap(3).

the host owner (/dev/hostowner) owns all devices, including cap(3),
which works well in existing use `as intended', but for non-overlapping shared
use of a single-user terminal would probably require something
to set hostowner when it switches to a given user's session.

the draw devices would all change ownership too, but if that makes
things too open (because the current user can see all window contents),
then it probably isn't hard to record ownership on draw directories
(as for /net/tcp directories and a few other devices). 

the more serious problem is that there isn't a good paint program.

Re: [9fans] First-timer help

[Skip Tavakkolian]

would aan + drawterm be a solution?

> using VM/386 to multiplex window sessions is rather like virtualising the
> Unix system call layer to allow several IP stacks.  it seems just
> a little heavy-handed.  there is actually little difference between
> multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned:
> mainly configuration and a few small policy differences.
> 
> if each user is given a rio session, much as martin suggested,
> and it has its own name space (as with newns)
> it will use its own attach to the file server, and
> thus run with the desired file permissions.
> 
> /dev/user can be set using cap(3).
> 
> the host owner (/dev/hostowner) owns all devices, including cap(3),
> which works well in existing use `as intended', but for non-overlapping shared
> use of a single-user terminal would probably require something
> to set hostowner when it switches to a given user's session.
> 
> the draw devices would all change ownership too, but if that makes
> things too open (because the current user can see all window contents),
> then it probably isn't hard to record ownership on draw directories
> (as for /net/tcp directories and a few other devices). 
> 
> the more serious problem is that there isn't a good paint program.

Re: [9fans] First-timer help

[Martin C. Atkins]

On Tue, 19 Jul 2005 16:38:40 +0100 Charles Forsyth <forsyth@terzarima.net> wrote:
> using VM/386 to multiplex window sessions is rather like virtualising the
> Unix system call layer to allow several IP stacks.  it seems just

I completely agree that it would be a sledge hammer to crack a nut in
this case. VM/x86 does give you somewhat more than just solving the
current tread topic, though...

> a little heavy-handed.  there is actually little difference between
> multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned:
> mainly configuration and a few small policy differences.
etc

That is nice to hear. I seem to understand more than I realised :-)!

> the more serious problem is that there isn't a good paint program.

My daughter would agree with that!

Martin

-- 
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] First-timer help

[Tim Newsham]

> using VM/386 to multiplex window sessions is rather like virtualising the
> Unix system call layer to allow several IP stacks.  it seems just
> a little heavy-handed.  there is actually little difference between
> multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned:
> mainly configuration and a few small policy differences.

I don't think he was suggesting a seperate DomU per user, but
rather a seperate (virtual) graphics device per user.  I
think the xen approach will be to use the VNC protocol to provide
access to DomU graphics.  I don't see why multiple VNC's couldnt
be supported.

> the host owner (/dev/hostowner) owns all devices, including cap(3),
> which works well in existing use `as intended', but for non-overlapping shared
> use of a single-user terminal would probably require something
> to set hostowner when it switches to a given user's session.

Why not just change permissions on the various devices that
a user would want to access (ie. mouse, video and audio).  Or
probably better -- just multiplex these and provide a virtual
device.  How hard would it be to make a generic multiplexer
that took in a filesystem prototype file and then virtualized
access to each of the devices for a number of children processes?

> the more serious problem is that there isn't a good paint program.

Nor internet chess client ;-)

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] First-timer help

[Brian L. Stuart]

In message <20050719113153.6a05a689@localhost.localdomain>, "Martin C. Atkins" 
writes:
>On Mon, 18 Jul 2005 12:45:32 +0200 lucio@proxima.alt.za wrote:
>"Plan 9 way" of dealing with this be to run a multiplexer process
>pre-login, that multiplexes access to /dev/draw(etc) across several
>virtual consoles, and puts a login process in each one? Could that be
>done with the current mechanisms? I guess it would have worked with 8

I've avoided chiming in on this one because the whole thing
seemed a very non-Plan 9 thing and because I've never worked
that way or needed that behavior.  But this suggestion has
piqued my interest.

>From the user's perspective I'm picturing something along the
lines of a new menu entry in rio that is, say, Suspend.  When
that is selected, the current set of windows all "go away"
(really hidden but no longer accessible from the menu) and
are replaced by a dialog that lets you select a suspended
session or to start a new one.  Both options would require
a password.  As other's have mentioned, this password doesn't
provide any real security.  It's just there to make it hard
for your daughter to save her latest artistic masterpiece
on top of your latest coding masterpiece.

As to implementation, I'm thinking that on boot the multiplexer
starts up running as the machine owner.  As has also been
mentioned, it has a capability to change /dev/user which
it does each time it brings up a new or suspended session.
On creating a new session, it creates a new child process
running as the new user and serves the usual /dev stuff to
the child process.  The only change to rio would be the new
menu entry that would result in a note to the multiplexer
or a message to some other file it serves.  The behavior
could either be controlled by a command line switch or
rio could look for the multiplexer process and do the right
thing when it's found.

I know from experience how dangerous it can be to throw
out ideas as I think them up.  But it's up the flagpole
now.  Anybody interested in saluting or is this one that
would be better off burried?

BLS

Re: [9fans] First-timer help

[Steve Simon]

> ...I can't lose all my context (of active windows,
> etc), when my wife needs to check her email, ...

If you have a cpu server then you can always cpu to it as a different
user using the -u option. If you have just a single standalone machine
you can do the same by running keyfs and listen in /bin/termrc.local

This does not give the new user ownership of your terminal's devices
so some some more fiddling is needed - E.G. you will need to start another
factotum and upas/fs. It does give you somthing like unix's su(1) command
but that is what you would use under *nix isn't it?

-Steve

Re: [9fans] First-timer help

[Tim Newsham]

> This does not give the new user ownership of your terminal's devices
> so some some more fiddling is needed - E.G. you will need to start another
> factotum and upas/fs. It does give you somthing like unix's su(1) command
> but that is what you would use under *nix isn't it?

There's already an su-like tool: auth/login (excercise for the reader: 
alter auth/login to allow the host owner to switch without providing a 
password).  You can also switch users more violently with the cons 
filesystem (/dev/hostowner).

> -Steve

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] First-timer help

[arisawa]

> There's already an su-like tool: auth/login (excercise for the reader: 
> alter auth/login to allow the host owner to switch without providing a 
> password).  You can also switch users more violently with the cons 
> filesystem (/dev/hostowner).
>

su is already exist that allow the host owner to switch without 
providing a password.
I wrote:
> If you do want something like UNIX su command,
> try
> 	http://plan9.aichi-u.ac.jp/netlib/cmd/su-1.4/
>
> su is useful if you want instantaneously change your user ID.
>

Kenji Arisawa

Re: [9fans] First-timer help

[Tim Newsham]

> also if you are certain you've rebooted (eg, little reset button
> or perhaps power cycle) there's much less chance that preceding
> person using the same terminal has left something lurking
> (such as a fake login screen for instance, which UNIX has had
> almost from the beginning)

Yah, now you're just trusting the bios, the local disk (if any)
and the network.  Much more secure ;-)

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] First-timer help

[Ronald G. Minnich]

On Wed, 20 Jul 2005, Tim Newsham wrote:

> Yah, now you're just trusting the bios, the local disk (if any)
> and the network.  Much more secure ;-)

it will be even more fun with the newer BIOSes (e.g. EFI) that support 
arbitrary driver modules, tasks, and can even run programs. All stored on 
a flash file system on the mainboard. 

This will make life interesting. 

ron

Re: [9fans] First-timer help

[Richard Miller]

> it will be even more fun with the newer BIOSes (e.g. EFI) that support 
> arbitrary driver modules, tasks, and can even run programs. All stored on 
> a flash file system on the mainboard. 

Didn't HP (many years ago) make a desktop machine with Unix in ROM?

-- Richard

Re: [9fans] First-timer help

[Charles Forsyth]

>>Didn't HP (many years ago) make a desktop machine with Unix in ROM?

i believe it was the inspiration for subsequent clones: nothing ever really can change.

Re: [9fans] First-timer help

[Gorka guardiola]

Yes, ancient greeks already booted their flavours of Unix from the Bios...

On 7/22/05, Charles Forsyth <forsyth@terzarima.net> wrote:
> >>Didn't HP (many years ago) make a desktop machine with Unix in ROM?
> 
> i believe it was the inspiration for subsequent clones: nothing ever really can change.
> 


-- 
- curiosity sKilled the cat

Re: [9fans] First-timer help

[Wes Kussmaul]

Richard Miller wrote:

> Didn't HP (many years ago) make a desktop machine with Unix in ROM?

Wasn't someone who's very familiar to us involved in LinuxBIOS?

-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information. If you are not 
the intended recipient, please notify attorney Mort Hapless at Vulner, 
Exposed & Wideopen LLP immediately at either (781) 647-7178, or at 
ohoh@vulex.com, and destroy all copies of this message and any 
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t 
stop reading that confidential stuff about our client you’re in big 
trouble. OK, we’re the ones in trouble but we’ll find a way to go after 
you, or at least we think we may be able to. Look, we’re begging you. 
Just click the delete button and move on to a message that concerns you, 
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group 
(village.com) ensure that only intended recipients receive your 
confidential messages.

Re: [9fans] First-timer help

[David Leimbach]

On 7/22/05, Richard Miller <9fans@hamnavoe.com> wrote:
> > it will be even more fun with the newer BIOSes (e.g. EFI) that support
> > arbitrary driver modules, tasks, and can even run programs. All stored on
> > a flash file system on the mainboard.
> 
> Didn't HP (many years ago) make a desktop machine with Unix in ROM?
> 
> -- Richard
> 

SRM firmware was almost unixy enough on DEC Alphas...  But it could be
"interesting" at times

>

Re: [9fans] First-timer help

[jmk]

The firmware we used in the Hobbit boards we built a few years ago
was a Plan 9 Hobbit kernel with a different address mapping, a segment
mapping physical memory available to segattach and a different /boot
programme. You could attach to a fileserver to get programmes to boot.
You could also execute programmes from the fileserver, like rc...

--jim

On Fri Jul 22 11:37:04 EDT 2005, leimy2k@gmail.com wrote:
> On 7/22/05, Richard Miller <9fans@hamnavoe.com> wrote:
> > > it will be even more fun with the newer BIOSes (e.g. EFI) that support
> > > arbitrary driver modules, tasks, and can even run programs. All stored on
> > > a flash file system on the mainboard.
> > 
> > Didn't HP (many years ago) make a desktop machine with Unix in ROM?
> > 
> > -- Richard
> > 
> 
> SRM firmware was almost unixy enough on DEC Alphas...  But it could be
> "interesting" at times
> 
> >

Re: [9fans] First-timer help

[LiteStar numnums]

If by 'interesting' you mean 'a rather odd conglomerate of Unix and
OpenVMS smashed into a small space', then I would agree. It was even
more fun to boot WinNT on my first alpha... and try to figure out how
to disable the stupid ARC junk... =)
-- Stefan

On 7/22/05, David Leimbach <leimy2k@gmail.com> wrote:
> On 7/22/05, Richard Miller <9fans@hamnavoe.com> wrote:
> > > it will be even more fun with the newer BIOSes (e.g. EFI) that support
> > > arbitrary driver modules, tasks, and can even run programs. All stored on
> > > a flash file system on the mainboard.
> >
> > Didn't HP (many years ago) make a desktop machine with Unix in ROM?
> >
> > -- Richard
> >
> 
> SRM firmware was almost unixy enough on DEC Alphas...  But it could be
> "interesting" at times
> 
> >
> 


-- 
In possibility the eternal, rightly understood, continually lays out
only a small piece at a time
In possibility the eternal is continually near enough to be at hand
and yet far enough away to keep man advancing towards the
eternal, on the way, in forward movement. In this way the ternal lures
and draws a person, in the possible, from craddle to grave
if he just chooses to hope
   <<Soren Kierkegaard>>

Re: [9fans] First-timer help

[Ronald G. Minnich]

On Fri, 22 Jul 2005, LiteStar numnums wrote:

> If by 'interesting' you mean 'a rather odd conglomerate of Unix and
> OpenVMS smashed into a small space', then I would agree. It was even

clear sign that SRM was over the top: it had a 'ps' command. 

could play yellow rose of texas if you typed the right command

to format disks, you used a command and a ps and a grep to see when it was 
done (IIRC)

Nuts. 

ron

Re: [9fans] First-timer help

[Dave Eckhardt]

>> also if you are certain you've rebooted (eg, little reset button
>> or perhaps power cycle) there's much less chance that preceding
>> person using the same terminal has left something lurking

> Yah, now you're just trusting the bios, the local disk (if any)
> and the network.  Much more secure ;-)

If you can't trust the BIOS, you can't trust *anything* about
the machine.  There are business-card-sized CD-R's, so if you
do trust the BIOS you can have a read-only bootable system in
your wallet at all times.  If you use the disk only for a
"cfs -r", you don't need to trust its contents.

What's the nature of the interaction between factotum and the
auth server?  If somebody who owns the network can interpose
themselves between you and the auth server, can they end up
with your password, or at least authenticate once as you?

Dave Eckhardt

Re: [9fans] First-timer help

[Russ Cox]

> What's the nature of the interaction between factotum and the
> auth server?  If somebody who owns the network can interpose
> themselves between you and the auth server, can they end up
> with your password, or at least authenticate once as you?

no.

of course, if they can interpose between you and the 
file server then they can probably hijack the connection
after you've authenticated.

russ

Re: [9fans] First-timer help

[Wes Kussmaul]

Dave Eckhardt wrote:

> If you can't trust the BIOS, you can't trust *anything* about
> the machine.  

I want a bios that is digitally signed by multiple properly-enrolled 
professionally licensed individuals, with those licenses being signed by 
city hall. The licenses should include:

code developer
code auditor
building inspector

None of these should be the usual worthless organizational code signing 
signatures. (Right after the serpent said "try this fruit" he added, "by 
the way, it's ok if the 'Arthur Andersen' signature means 'a bunch of 
people collectively calling themselves Arthur Andersen.") The biometrics 
of the signers should be on file, signed by the enrollment officer, who 
is a Latin Notary.

The bios should be able to do only one thing: hand over control to a 
similarly code-signed hypervisor, and only if everything is kosher.

> There are business-card-sized CD-R's, so if you
> do trust the BIOS you can have a read-only bootable system in
> your wallet at all times.  

LNX-BBC is a good one:

http://www.lnx-bbc.org/

However: a cd will last about a month in your wallet before it's no 
good. Unless you have a rigid wallet.

-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments 
to this message are intended for the exclusive use of the addressee(s) 
and may contain confidential or privileged information. If you are not 
the intended recipient, please notify attorney Mort Hapless at Vulner, 
Exposed & Wideopen LLP immediately at either (781) 647-7178, or at 
ohoh@vulex.com, and destroy all copies of this message and any 
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t 
stop reading that confidential stuff about our client you’re in big 
trouble. OK, we’re the ones in trouble but we’ll find a way to go after 
you, or at least we think we may be able to. Look, we’re begging you. 
Just click the delete button and move on to a message that concerns you, 
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group 
(village.com) ensure that only intended recipients receive your 
confidential messages.

Re: [9fans] First-timer help

[Tim Newsham]

>> Yah, now you're just trusting the bios, the local disk (if any)
>> and the network.  Much more secure ;-)
>
> If you can't trust the BIOS, you can't trust *anything* about
> the machine.

The original thread mentioned false login screens that people
can leave running in unix.  What I meant to imply (perhaps too
subtly) was that you can configure the BIOS to boot a malicious
plan9 kernel (by adjusting bios parameters, by leaving a
boot block on the disk, or by interposing on the network boot
process).  Rebooting the machine does not necessarily give you
strong assurances against trojan login screens.  (Of course
it can, if configured properly -- ie trusted booting of signed
binaries).

Sure you can put a tiny cdr into the drive, but what if the
bios doesn't even boot the cdr (or refuses to, and has a password).
What if it boots the hard drive while making it look like its
booting the CDR?

> Dave Eckhardt

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] First-timer help

[Dave Eckhardt]

> Sure you can put a tiny cdr into the drive, but what if the bios
> doesn't even boot the cdr (or refuses to, and has a password).
> What if it boots the hard drive while making it look like its
> booting the CDR?

But my hypothetical CD-R kernels all print "Say farewell to Nova
Scotia" on the screen just before entering user space for the first
time.  Or maybe it's only the kernels I boot on Mondays which use
that particular message.

Of course, *any* trust placed in a computing device other people
have control over is risky (much fun could be had by storing away
compressed snapshots of video memory every 5 minutes...all you
need is a way to convince my kernel to call into the BIOS
periodically...hmmm...how about that APM entry point?).

You always need to draw a line somewhere.

Dave Eckhardt

Re: [9fans] First-timer help

[Charles Forsyth]

looking at it the other way, i'm quite grateful that the
bios will still let me boot something other than windows (or linux)

Re: [9fans] First-timer help

[Ronald G. Minnich]

On Thu, 21 Jul 2005, Dave Eckhardt wrote:

> If you can't trust the BIOS, you can't trust *anything* about the
> machine.  There are business-card-sized CD-R's, so if you do trust the
> BIOS you can have a read-only bootable system in your wallet at all
> times.  If you use the disk only for a "cfs -r", you don't need to trust
> its contents.

it's almost always assumed by people on this list that all computers have
an orifice of some sort or another into which bootable media can be poked.  
I don't know why.

ron

Re: [9fans] First-timer help

[David Leimbach]

On 7/21/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> 
> On Thu, 21 Jul 2005, Dave Eckhardt wrote:
> 
> > If you can't trust the BIOS, you can't trust *anything* about the
> > machine.  There are business-card-sized CD-R's, so if you do trust the
> > BIOS you can have a read-only bootable system in your wallet at all
> > times.  If you use the disk only for a "cfs -r", you don't need to trust
> > its contents.
> 
> it's almost always assumed by people on this list that all computers have
> an orifice of some sort or another into which bootable media can be poked.
> I don't know why.

Yeah, that's sooo 1980s :)

> 
> ron
>

Re: [9fans] First-timer help

[Russ Cox]

> it's almost always assumed by people on this list that all computers have
> an orifice of some sort or another into which bootable media can be poked.
> I don't know why.

because that's the case everyone except you is familiar with.  ;-)

russ

Re: [9fans] First-timer help

[Ronald G. Minnich]

On Thu, 21 Jul 2005, Russ Cox wrote:

> because that's the case everyone except you is familiar with.  ;-)

ha! Well, boot this:
http://www.nasa.gov/images/content/122980main_05pd1616.jpg

:-)

ron

Re: [9fans] First-timer help

[lucio]

> ha! Well, boot this:
> http://www.nasa.gov/images/content/122980main_05pd1616.jpg

What?!  No illuminated console toggle-switches?!

++L

Re: [9fans] First-timer help

[andrey mirtchovski]

> And why do you have to reboot in order to change users?  UNIX has had 
> that from the beginning, and I don't see any reason to drop it.

this isn't unix :) 

the single most-important reason to switch users (do something as
root) does not exist here, hence nobody bothered.  when you set up a
proper file/cpu/auth server on which you're going to have more than
one users then you can always log in as the administrative user
(bootes, in most cases) remotely or on the console of the server and
administer.  if you only have a standalone, single-user machine you're
considered its owner.

in short, you'll need to set-up a standalone cpu/auth server to get
passwords.  the instructions are on the wiki.

have you read "plan 9 from bell-labs" and "security in plan9"?  they
contain some of the rationale for this setup.

Re: [9fans] First-timer help

[John Floren]

andrey mirtchovski wrote:
>>And why do you have to reboot in order to change users?  UNIX has had 
>>that from the beginning, and I don't see any reason to drop it.
> 
> 
> this isn't unix :) 
> 
> the single most-important reason to switch users (do something as
> root) does not exist here, hence nobody bothered.  when you set up a
> proper file/cpu/auth server on which you're going to have more than
> one users then you can always log in as the administrative user
> (bootes, in most cases) remotely or on the console of the server and
> administer.  if you only have a standalone, single-user machine you're
> considered its owner.
So when I'm not around and somebody decides to boot the computer and 
delete all my files, that's just okay then?
> in short, you'll need to set-up a standalone cpu/auth server to get
> passwords.  the instructions are on the wiki.
> 
> have you read "plan 9 from bell-labs" and "security in plan9"?  they
> contain some of the rationale for this setup.
> 
> .
> 


-- 
http://nuwen.net/~digi/cluster
<knghtbrd> He's a about half the size of the others.
<knghtbrd> But he's got a chainsaw.

Re: [9fans] First-timer help

[andrey mirtchovski]

> So when I'm not around and somebody decides to boot the computer and 
> delete all my files, that's just okay then?

sure, it happens to me all the time :)

would you like an account on one of the open-to-everybody Plan 9
installations to see how it looks and feels in a real environment?
if yes, check http://www.9grid.de or http://www.tip9ug.jp

Re: [9fans] First-timer help

[John Floren]

andrey mirtchovski wrote:
>>So when I'm not around and somebody decides to boot the computer and 
>>delete all my files, that's just okay then?
> 
> 
> sure, it happens to me all the time :)
> 
> would you like an account on one of the open-to-everybody Plan 9
> installations to see how it looks and feels in a real environment?
> if yes, check http://www.9grid.de or http://www.tip9ug.jp
> 
> .
> 
I've already sent an account request to the Japanese grid; I'll check 
out the German one as well.  So, on one of these big installations, the 
files are better protected, yes?
Thanks

Digi
-- 
http://nuwen.net/~digi/cluster
<knghtbrd> He's a about half the size of the others.
<knghtbrd> But he's got a chainsaw.

Re: [9fans] First-timer help

[andrey mirtchovski]

> I've already sent an account request to the Japanese grid; I'll check 
> out the German one as well. 

there's a US "free-for-al"l Plan 9 installation too, which may be closer
to you: http://www.9grid.us

> So, on one of these big installations, the 
> files are better protected, yes?

generally -- yes.  only its owner (the user who started the file
server) can access the administrative "area" on a file server, i.e.
/srv/fscons.  there's only a single point of entry to allow one to
modify files belonging to other users and that is the rather
complicated dance of connecting to /srv/fscons, changing permissions
of a file, disconnecting and then modifying it.

if you feel adventurous you can set up an old-style (ken fs, as they're
called) file server which completely disallows the running of any user
processes.  on such machine there's no way to modify another user's
files unless you're behind the keyboard/console of the machine or the
user changes permissions to allow you to do so.

if you add your user to the group 'sys' you will be able to handle
most daily administrative tasks such as updating the system or
recompiling binaries from sources.  that's why most directories are
group-writable and those bits are extended recursively when creating
new files.

andrey

Re: [9fans] First-timer help

[Russ Cox]

> generally -- yes.  only its owner (the user who started the file
> server) can access the administrative "area" on a file server, i.e.
> /srv/fscons.  there's only a single point of entry to allow one to
> modify files belonging to other users and that is the rather
> complicated dance of connecting to /srv/fscons, changing permissions
> of a file, disconnecting and then modifying it.
> 
> if you feel adventurous you can set up an old-style (ken fs, as they're
> called) file server which completely disallows the running of any user
> processes.  on such machine there's no way to modify another user's
> files unless you're behind the keyboard/console of the machine or the
> user changes permissions to allow you to do so.

you can just as easily set up a fossil server that doesn't let
users cpu into the machine, and it will be just as isolated 
as an old ken fs.

russ

Re: [9fans] First-timer help

[Christopher Nielsen]

On Sun, Jul 17, 2005 at 12:47:55PM -0700, John Floren wrote:
> andrey mirtchovski wrote:
> >>And why do you have to reboot in order to change users?  UNIX has had 
> >>that from the beginning, and I don't see any reason to drop it.
> >
> >
> >this isn't unix :) 
> >
> >the single most-important reason to switch users (do something as
> >root) does not exist here, hence nobody bothered.  when you set up a
> >proper file/cpu/auth server on which you're going to have more than
> >one users then you can always log in as the administrative user
> >(bootes, in most cases) remotely or on the console of the server and
> >administer.  if you only have a standalone, single-user machine you're
> >considered its owner.
>
> So when I'm not around and somebody decides to boot the computer and 
> delete all my files, that's just okay then?

in a full P9 system, files are not stored locally; typically,
terminals are completely diskless. files are stored on and
protected by a fileserver. regular users cannot connect to
the fileserver without first authenticating themselves through
an auth server, so your files are safe from deletion.

you're thinking of P9 as a standalone, single system when it is,
in fact, a distributed system usually made up of several hosts.

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] First-timer help

[Charles Forsyth]

>>So when I'm not around and somebody decides to boot the computer and 
>>delete all my files, that's just okay then?

they could anyway, at least with Linux.  (boot the installation/recovery
CD and get a root shell.  even without the shell, at the very least all
the ones i've used recently allow me to wipe an existing installation
and replace it with a  new one.  i enjoy that.)

Re: [9fans] First-timer help

[Dave Lukes]

On 18 Jul 2005, at 00:17, Charles Forsyth wrote:

>>> So when I'm not around and somebody decides to boot the computer and
>>> delete all my files, that's just okay then?
>
> they could anyway, at least with Linux.  (boot the 
> installation/recovery
> CD and get a root shell.  even without the shell, at the very least all
> the ones i've used recently allow me to wipe an existing installation
> and replace it with a  new one.  i enjoy that.)

This is all interesting but pretty much irrelevant.

If you store data on a machine to which other people have physical 
access,
there are many simple ways for them to remove or tamper with it.

Many of these methods (powerful magnet, hammer, open the case and steal 
the drive(s))
are pretty much hardware- and OS-independent.

"This system is secure until removed from the hermetically sealed 
Faraday caged concrete box".

That is one of the reasons why plan9 regards "your computer" as being
a network terminal with some computing capability rather than a 
mainframe on your desktop.

     DaveL.

Re: [9fans] First-timer help

[lucio]

> "This system is secure until removed from the hermetically sealed 
> Faraday caged concrete box".

>From the "I can't resist a jab" department: Windows NT (3.51, if
memory serves) was C2-certified, on condition it wasn't networked.  I
wonder if anything in that area has changed?

No need for me to emphasise the futility of the certification.

++L

Re: [9fans] First-timer help

[Jack Johnson]

On 7/17/05, Dave Lukes <davel@anvil.com> wrote:
> If you store data on a machine to which other people have physical
> access, there are many simple ways for them to remove or tamper with it.

I remember seeing USB fingerprint scanners in some random store a few
years back and laughed hysterically when I saw that particular brand
was compatible with Windows 98 only.

Sure, pretty much any physical access will let you in, but some
portals are easier to squeeze through than others (pun intended).

-Jack

Re: [9fans] First-timer help

[David Leimbach]

On Jul 18, 2005, at 8:24 AM, Jack Johnson wrote:

> On 7/17/05, Dave Lukes <davel@anvil.com> wrote:
>
>> If you store data on a machine to which other people have physical
>> access, there are many simple ways for them to remove or tamper  
>> with it.
>>
>
> I remember seeing USB fingerprint scanners in some random store a few
> years back and laughed hysterically when I saw that particular brand
> was compatible with Windows 98 only.
>
> Sure, pretty much any physical access will let you in, but some
> portals are easier to squeeze through than others (pun intended).


Our "first timer" doesnt' realize that Plan 9 defaults to "terminal  
mode" on install.

The reasoning behind this "easy access to files" is that you  
shouldn't be keeping your
files on a local machine.  Plan 9 was designed for grids with I/O  
nodes that have some
physical security.  While you "can" run most anything you want in  
terminal mode it's not
the originally intended configuration for the OS.

I still like this model better, there is no root user, though there  
is a filesystem owner
which I guess is similar.

Personally, the first thing I do when I install plan 9 is to compile  
a cpu/fs/auth kernel
and switch to that after a bit of testing.  Then I drawterm in.  I  
can have many users but there
is still only one "owner" for those files on the system.

What I wonder about is how to make it so not just anyone can do "con / 
srv/fscons" and get full
access to the files :).

I'm still pretty new to all of this too, mainly due to sporadic spare  
time to play around with it.

Dave

>
> -Jack
>

Re: [9fans] First-timer help

[Ronald G. Minnich]

On Sun, 17 Jul 2005, John Floren wrote:

> So when I'm not around and somebody decides to boot the computer and delete
> all my files, that's just okay then?

this is not unix. It is really not unix. The question you are posing makes
no real sense. 

By now, somebody has answered better than this, but I thought I would 
reinforce the message.

ron

Re: [9fans] First-timer help

[arisawa]

On Sun, 17 Jul 2005, John Floren wrote:

> So when I'm not around and somebody decides to boot the computer and 
> delete
> all my files, that's just okay then?

this remind me that I forgot win2000 password.
I decided to reboot the computer and reinstalled the OS.
I didn't know how to rescue my data.

Yes, that should be OK.

Kenji Arisawa

Re: [9fans] First-timer help

[Jack Johnson]

On 7/18/05, arisawa@ar.aichi-u.ac.jp <arisawa@ar.aichi-u.ac.jp> wrote:
> this remind me that I forgot win2000 password.
> I decided to reboot the computer and reinstalled the OS.
> I didn't know how to rescue my data.

There is a fun trick you can do on NT/2K/XP (though it's less
effective on XP) if you have a Win2K installation CD.

If you've forgotten/lost the local administrator's password (and other
administrative accounts are otherwise unavailable), you can use the
Win2K installation CD to boot to a recovery console.  The XP
installation CD correctly prompts you for the local administrative
password, but the 2K CD does not, even for XP installations.

You cannot easily change the administrative password from the recovery
console, but you can modify certain files.  The trick is to rename the
default screensaver (logon.scr usually), and just copy the command
prompt in it's place (cmd.exe), then reboot and wait.

After x minutes the system will happily give you a command prompt with
system-level privileges.  If the machine is on a domain, the machine
itself still has a domain account, and any network share that allows
Everyone read/write access is available, so you can map the share to a
drive and backup your files or take other measures to recover your
data. The command line FTP client would work just as well, I suppose.

USB support seems to be limited, though.

-Jack

Re: [9fans] First-timer help

[Tim Wiess]

> I've already read through the wiki.  I did run newuser after I manager 
> to login as my new user.  However, I still cannot set any passwords, so 
> logging in is kinda insecure.

    The user authentication methods used in P9 are a little different than
    unix. Read up on keyfs(4) and factotum(4). Basically P9 was designed
    to have terminals authenticate themselves to a separate CPU or
    authentication server.


> And why do you have to reboot in order to change users?  UNIX has had 
> that from the beginning, and I don't see any reason to drop it.

    Again P9's an entirly different system. There are many
    similarities with Unix, but there are far more differences. And
    thinking in terms of Unix when dealing with P9 will most likely
    just lead to frustration and confusion.

    It may take a little time to get over the hurdle of adapting to a
    new environment, but your paitence and efforts will be rewarded
    many times over.

    If you haven't already, start reading the docs in /sys/doc or
    http://www.cs.bell-labs.com/sys/doc/

Re: [9fans] First-timer help

[arisawa]

> Gorka guardiola wrote:
>> http://www.cs.bell-labs.com/wiki/plan9/Adding_a_new_user/
>> After, when you log in for the first time run
>> /sys/lib/newuser
>> look at the wiki (url above) for this kind of information.
> I've already read through the wiki.  I did run newuser after I manager 
> to login as my new user.  However, I still cannot set any passwords, 
> so logging in is kinda insecure.
> And why do you have to reboot in order to change users?  UNIX has had 
> that from the beginning, and I don't see any reason to drop it.
> Thanks
>

If you do want something like UNIX su command,
try
	http://plan9.aichi-u.ac.jp/netlib/cmd/su-1.4/

su is useful if you want instantaneously your user ID.

Kenji Arisawa

Re: [9fans] First-timer help

[arisawa]

sorry

> su is useful if you want instantaneously your user ID.
>

change to:
	su is useful if you want instantaneously change your user ID.

Kenji Arisawa

Re: [9fans] First-timer help

[andrey mirtchovski]

start with this one:

http://cm.bell-labs.com/wiki/plan9/plan_9_wiki/index.html

yes, you do have to reboot when you want to change users. make sure you log
in as the new user when you run auth/changeuser.

Re: [9fans] First-timer help

[andrey mirtchovski]

> yes, you do have to reboot when you want to change users. make sure you log
> in as the new user when you run auth/changeuser.

make that '/sys/lib/newuser', my bad

[9fans] Re: First-timer help

[Dave Eckhardt]

> I then ran "auth/changeuser john" and tried to set my password,
> but I got a "permission denied" error.  Help?

My apologies for the vague answer, but: every time I've run
auth/changeuser (running as bootes on my auth/fossil/venti file
server) I've got a "permission denied" error which appears to be
harmless, since the accounts are created and people can log in.
I haven't chased it down beyond that.

> And why do you have to reboot in order to change users?
> UNIX has had that from the beginning, and I don't see any
> reason to drop it.

Plan 9 was designed around a particular distributed system
architecture (see the "Plan 9 From Bell Labs" paper at
http://cm.bell-labs.com/sys/doc/index.html).  There are
basically three kinds of machine:

* critical infrastructure, such as authorization and reliable file
  storage, which define identity and trust for the multi-user
  computing environment--these are typically accessible by only
  trusted system administrators and located in physically secure
  environmentally-controlled locations,

* shared "CPU servers", whose configuration, policies, and hardware
  are owned by the system administrators, but which can be used
  in a restricted fashion by multiple users simultaneously,

* public-access "terminals", which will allow any user to boot
  them running any code--think of a standard PC, where whoever
  sticks a floppy into the drive can do anything they wish.

Other models are possible.  For example, Amoeba was designed
for "processor pools", racks of CPU servers each one of which
was used by one user at a time.

In order to have multiple users running on a public-access
terminal, you have to define what you would mean by that,
which isn't easy.  Who should own a particular serial line
or USB port?  If Alice boots a kernel she just wrote, should
Bob trust it to keep his password secret?  Should Bob be able
to reboot the machine to use a different kernel if Alice is
running some long computation?

These questions are architecturally answered for Plan 9 file
servers (nobody logs in), and CPU servers (people can log in,
but not reboot, modify configuration, or control hardware).
The answer for terminals is "one person owns the machine at
a time and can do anything to it".  Rebooting is a simple
way to ensure that *everything* on the machine belongs to
one user at a time.

Dave Eckhardt