Password file

EEA index

FileStore
Description
Hardware
Error codes
NVRAM
Disc format
Disc image
Accessing
Password file
E01 vs E01S
Rescuing
Emulator
SD card

Intro
MDFS
Others
Clocks
Bridges
Interfaces
Misc h/w
Testing
Misc info

Introduction

The password file resides on the root of a valid server disc as $.Passwords. By default its access is L/ which means it is not accessible (except to the server). This is to prevent accidental deletion which can really mess things up.

It is my understanding that all valid discs must have a password file. However, there is no reason why the password file (on, for example, a floppy), cannot be empty.

When you *FSFormat a floppy disc, it writes a blank password file containing one entry - Syst, with no password.

As this user, created by default was a disc is formatted, will have system manager level access and no password, it is imperative to either remove the account or provide a password.
If you are really sly, you could leave "Syst" but make it a Locked user!!!

The password file format specified below is compatible with Level 3, FileStore and awServer.
There are various tools available for editing the password file, but I (obviously) would recommend my !BudgieMgr software!

Level 4 user files are very different. The Level 4 server comes supplied with a user editor, but this editor cannot cope with the older type of password file. However, the product I recently mentioned can cater for both types of user file! ☺

 

File format

Each user in the password file format has 31 bytes to describe them. The file must be padded out to a whole sector (file size must be a multiple of 256 bytes) so the only clear way to count the number of users is to step through the file and see how many there are.
Byte(s) Meaning
 
0 - 19 Twenty bytes for username, null terminated if less than twenty characters.
A null username indicates that the user has been deleted.
 
20 - 25 Six bytes for password, null terminated if less than six characters.
Passwords cannot be longer than six characters.
 
26 - 29 A long integer (32 bits) for user free space.
The server maintains space accounting to prevent a user from hogging too much space on the disc.
You may run into this yourself - if you run a private network in your bedroom and you start getting "Disc full" (etc) errors when, clearly, the disc is not full - you will need to provide yourself with more space.
 
30 Boot option (lower four bits) and user privilege (upper four bits).
The possible values for the boot option are:
0 None
1 Load
2 Run
3 Exec
This is the same as *Opt 4, x.
 
The possible values for the privilege, with the lower four bits masked out, are:
0 System (i.e. %0000xxxx)
128 Normal (i.e. %0001xxxx)
160 Locked (i.e. %0101xxxx)
192 System (i.e. %1100xxxx) - the FileStore sets this in the default file

 

The user's files

The user name is also the User Root Directory. Therefore if the user is called Amelie, she will have read/write access to the files within $.Amelie.
If the URD is not present, the user will have read-only access to the root directory.

By default, files written to a user's URD are assigned RW/ access, which means Amelie would have full rights to her own files. Other users will be able to see what files she has (the contents of directories are not hidden) but they will not be able to access any of her files.
She could share files for reading by setting the access to something like RW/r, so others can load (but not modify) her files.
It is also possible to provide external write-only access to a file (i.e. WR/w). This is less common, but is used by the !MailMan application to allow you to drop mail into other people's mailboxes. You cannot 'read' messages that aren't your own, but you can send them... by appending to the mail file in their URD.

The final option is full access - such as WR/wr. This means the file may be read and written by anybody. The danger here is that it may also be erased by anybody. If you were to set the Locked attribute (i.e. WRL/wr), the file could not be deleted except by yourself. However a malicious user could blank the file which is as good as deleting it...
The problem comes, especially in harddisc installations, that there is no such thing as a group level access. If a class was working on a shared data project, any publically accessible data is accessible to everybody with an account on the server. It would be better handled by having the accessible data files read-only to everybody, and a very trustworthy student (or the teacher herself) given a special account with system level privilege which can access all of the accounts in the project to pull out and collate the data that would be world-accessible.
Not an ideal situation, but not a scenario that the FileStore was ever designed to cope with (and I'm not entirely certain if Level4 has 'groups'). The MDFS does, but then the MDFS is everything and then some...

 

Quirk warning!

The Level 2/3 user's guide states the following, and as the FileStore is essentially a ROM version of Level 3, this applies to that server as well:
You have owner access to your own main directory and sub-directories, but public access to any directory that you specify beginning with a $ or that you reach (using *DIR) via the root directory.

EXAMPLE

You log on as JOEY. You will have owner access to the files and sub-directories in the main directory JOEY. You will have public access to the contents of the main directory PHILIP, which you will have to specify as $.PHILIP. If you specify your own main directory as $.JOEY, instead of just JOEY, you will have only public access to it.

The situation is even worse on a RISC OS machine if you are using the command line (it's okay within the Desktop).
Consider the following transcript: 

*I Am Amelie
*.
Dir. Net::FSdisc.& Option 00 (Off) Owner
CSD  Net::FSdisc.&
Lib. Net::FSdisc.$

MyDoc        WR/   

*Dir $
*Dir Amelie
*.
Dir. Net::FSdisc.$.amelie Option 00 (Off) Public
CSD  Net::FSdisc.$.amelie
Lib. Net::FSdisc.$

MyDoc        WR/
So we log in as Amelie (no password) and we then go to the root directory and back again as stated in the example. But, look, you see the top line of the directory it said "Owner" in the beginning? Now it says "Public".

*Dir $.Amelie - won't work!
*Dir Amelie (from root) - won't work!

I can imagine things like this could freak out a generation of non-geeky schoolchildren. Without the obvious solution - logging out and back in again - how the heck is Amelie expected to get proper access to her files?

Transcript time again: 

*.
Dir. Net::FSdisc.$.amelie Option 00 (Off) Public
CSD  Net::FSdisc.$.amelie
Lib. Net::FSdisc.$

MyDoc        WR/  

*Dir &
*.
Dir. Net::FSdisc.& Option 00 (Off) Owner
CSD  Net::FSdisc.&
Lib. Net::FSdisc.$

MyDoc        WR/
There you have it! The venerable ampersand, hijacked by France Telecom (latterly "Orange") and used and abused by all manner of Internet-related stuff that thinks the 'at' is passé - forget all of that nonsense. The ampersand was doing something useful in Acorn filing systems over two decades ago. (nerr!)

The '&' not only restores your rightful user directory, it also restores your rightful access to the files that are rightfully yours. Righteous!

Copyright © 2009 Rick Murray