mahler (09/09/82)
Here are the manual pages announced in net.general ... fcp does the
copies and fmk edits the permission file. ---- Steve Mahler, Purdue
FCP(1) UNIX Programmer's Manual FCP(1)
NAME
fcp - friend copy
SYNOPSIS
fcp file1 file2
fcp file file ... directory
DESCRIPTION
_F_i_l_e_1 is copied onto _f_i_l_e_2. The mode and the group owner of
_f_i_l_e_2 are the same as that of _f_i_l_e_1.
If the last argument is a directory, one or more _f_i_l_e_s are
copied into the _d_i_r_e_c_t_o_r_y with their original file names
preserved. _F_c_p refuses to copy a file onto itself.
When copying a sorce file onto a destination file, the
source file should have read permission and the destination
file should have write permission. _F_c_p first checks to see
if there is standard permission on the source (destination)
file to be read (written). If this permission fails, the
HOME directory of the owner of the source (destination) file
is searched for a file named ._f_r_i_e_n_d. The ._f_r_i_e_n_d file has
entries that specify which users have access permissions on
certain files. The entries of the ._f_r_i_e_n_d file are of the
form:
user:file-full-path-name:permission:
For example, an entry could look like:
smith:/a/john/src/cal.c:w:
which means that user smith has write permission on the file
/a/john/src/cal.c
If a file is mentioned in the ._f_r_i_e_n_d file, it should
already exist. It is meaningless to give read/write permis-
sion to a user on a file that does not even exist. Espe-
cially, if the destination file does not exist _f_c_p would
fail and the source file will not be copied to the destina-
tion file (even if the destination file is in ._f_r_i_e_n_d file).
For example, if the file /a/john/src/cal.c does not exist,
user smith cannot invoke _f_c_p to copy a file over it despite
the fact that ._f_r_i_e_n_d shows that smith has write permission
on /a/john/src/cal.c.
If the destination file is ._f_r_i_e_n_d itself, _f_c_p fails to copy
a file over it. _F_c_p also fails if the mode of ._f_r_i_e_n_d file
is anything else but 0644 (see chmod(1)).
Printed 8/8/82 1
FCP(1) UNIX Programmer's Manual FCP(1)
SEE ALSO
fmk(1), cp(1)
Printed 8/8/82 2
FMK(1) UNIX Programmer's Manual FMK(1)
NAME
fmk - make and/or edit a .friend file
SYNOPSIS
fmk [ -u user ] [ -f file ] [ -p permission ] [ -w ] [ -d ]
DESCRIPTION
_F_m_k is invoked to either create or edit a file, called
._f_r_i_e_n_d, in the HOME directory of its caller. Editing the
file, could be either adding to or deleting from the ._f_r_i_e_n_d
file.
Information in ._f_r_i_e_n_d file is used by _f_c_p (see fcp(1)).
Each ._f_r_i_e_n_d file is consisted of a set of entries. Each
entry has the general format:
user:file-full-path-name:permission:
For example, an entry could look like:
smith:/a/john/src/cal.c:w:
which means that user smith has write permission on the file
/a/john/src/cal.c
If a file is mentioned in the ._f_r_i_e_n_d file, it should
already exist. It is meaningless to give read/write permis-
sion to a user on a file that does not even exist.
As illustrated above, each entry of the ._f_r_i_e_n_d file has
three fields. The three fields are _U_s_e_r, _f_i_l_e, and _p_e_r_m_i_s_-
_s_i_o_n. respectively. These fields are separated by colons.
If an entry is to be added to the ._f_r_i_e_n_d file, all three
fields should be given. That is, user, file, and permission
should all be specified.
The -u flag could be used to pass the user name when invok-
ing _f_m_k. Similarly, if the -f flag is used, a file name
should be specified by the user. If the file does not exist,
a warning to that effect is given. -w flag disables the
warnings. -p flag is used to specify the type of permission
user has on the file. Permission could be either 'r' or 'w'
standing for read and write respectively. When -d flag is
set, the entry is deleted from the ._f_r_i_e_n_d file.
If one or more fields are not specified when calling _f_m_k,
_f_m_k will prompt the user to specify the missing fields.
Using * as the value of a field implies that anything in
that specific filed is a match. Therefore, to delete all the
entries that give some sort of access permission to user
smith, one could simply type in:
Printed 8/8/82 1
FMK(1) UNIX Programmer's Manual FMK(1)
fmk -u smith -f \* -p \* -d
The backslashes (\) used in the above example are meant to
disable the special meaning of * to the command interpretter
(normally, * is expanded to the names of all the files in
the current directory). Note, however that, if _f_m_k itself
prompts the user for a file name, a backslash does not have
to precede * (should * be the answer). Let us again assume
that user john wants to delete all the entries that have
smith in their user fields. He invokes _f_m_k as follows:
fmk -d
Since no other field was specified, _f_m_k will prompt john for
the rest of information as illustrated below:
User's login name..........smith
Full file pathname.........*
Type of access (r/w).......*
In this case, * did not have to be preceded by a backslash.
If the entry to be deleted is not found in the ._f_r_i_e_n_d file,
_f_m_k prints out a warning to that effect. Invoking -w option,
disables the warning.
_F_m_k accepts only valid user names. If a user name is non-
existent, _f_m_k repeatedly prompts its caller until a valid
user name is given.
SEE ALSO
fcp(1), cp(1)
Printed 8/8/82 2barmar (09/11/82)
Congratulations! You have reinvented the Access Control List (ACL), something that Multics has had since the very beginning.