User authentication
This is almost straight forward. The cluster's uses the .passwd file in it's root directory to store usernames and passwords.
# su - cluster $ cat .passwd admin:secret-password:0:/u/admin root:another-secret-password:100:/u/root nobody:not-so-secret:1001: _:-:1002As you can see each line in the password file store 4 fields: the user's logon name, the password in cleartext, it's numerical user id and it's home directory. Anything else to say about this? I don't think so.
You can edit the .passwd file with the text editor of your choice. And you have to work this way if you want to delete (or better rename) a user or if you want to change his home directory. For more usual tasks you can use the passwd program or, better, do it from within server.
The last line is special. The passwd entry for the username `_'
does not describe a real user. It records the next numerical id the
passwd program should assign for a new user.
Creating users
It's possible (and recommended) to create new users from within the cluster server. Let's create a new user named new-user with secret-pw as his password and it's own home directory.
$ ftp localhost Connected to localhost. 220 server ready [030224-035610-02CB] - login please Name (localhost:cluster): admin 331 send password Password: 230 login accepted Remote system type is UNIX. Using binary mode to transfer files. ftp> site useradd new-user secret-pw /u/new-user 200 user created: 1005 ftp> mkdir /u/new-user 257 directory created ftp> site chown new-user /u/new-user 200 ok, owner changed ftp> ls /u 200 ok 150 listing follows drixr-xr-x 1 admin ftp 0 Feb 25 04:35 .. drwxr-xr-x 1 admin ftp 4096 Feb 25 02:53 admin drwxr-xr-x 1 new-user ftp 4096 Feb 25 04:31 new-user drwxr-xr-x 1 root ftp 4096 Feb 24 01:19 root 226 transfer complete ftp>
Passwords
Once you have populated your server with users you will notice that they sometimes forget their passwords.
ftp> site passwd new-user another-password 200 password changedA note about usernames and passwords. Usernames must be made of letter in the range a-z, digits, dots, plus- and minus signs. Empty passwords are permitted but passwords with only one character not. Users with a single character as password can't login.
Another note: Only the cluster administrator can create users, change other user's passwords or owner of files and/or directories. Normal users can only change their own password with the site password command.
So who is a (or better 'the') cluster administrator? This is hardcoded in the current - it's the cluster user with the user id 0, regardless of his or her name.
Permissions
Until here it was more or less straight forward. But permissions are difficult. To make it short: the FTP protocol doesn't talk about permissions and how to set o change them. Yes, there is a draft describing a permission scheme but it's not yet finalized.
For now I decided on a simple permission scheme based around users, a later release will be able to work with user groups. The server knows about the following access rights. These rights are granted one the complete contents of a directory. Assigning different permissions to particular files is not possible.
l - LIST, NLST, CWD
r - RETR
w - STOR, RNTO
d - DELE
m - MKD
s - RMD
n - RNFR
a - SITE CHOWN
As you can see the permission are more or less related to FTP commands.
But there are two command variants not mentioned above. If the
STOR or RNTO would overwrite an existing file
the executing user must have also delete permissions on the target
file. Why delete permission? Because the user could first delete the
target and then do the desired operation. So I see overwriting
operations as compound commands.
Granting and denying permission
Ok, now you know the different permissions. How are they applied?
Every user has lr rights on the cluster's root directory.
Permissions may be set in each directory in the .permissions
file:
# permissions for /linux # Give user `root', uid 1000, list, read and write access. 1000 lrw # The moderator, uid 1001, can also delete files. 1001 lrwd # No one else has access to /linux *As you see the .permissions format is simple: the user's id followed by his permissions. Notice that it's important to assign the users at
lr rights because permissions don't accumulate.
You set permissions, you don't addi them. Leaving the permission field
empty assigns no permissions and the star * defines a default.
If you have for a user more than one permission entry the last one
wins.
Access permissions based on a .permissions file are also valid on sub directories. So root has the the right shown above if the directory /linux/alpha if there isn't a .permission file telling something else.
Automatic permissions by ownership
Ok, this was one of the two central permission rules. The other one is that the file's or directory's owner can do everything with the file he likes, even if the .permissions file says something else. I simply don't see the point in denying a user rights on his files. If you don't like this in a directory context since this grants the directory owning user to delete files of other users you can simply change the owner of that directory.
The cluster administrator
Just to mention it: the cluster administrator has absolute power to do whatever he or she likes. No questions, no denial.