From petravic@fnal.gov Mon Oct 22 11:38:40 2001
Subject: Anonymous ftp dcache access
Don Petravick's desiderata for "anonymous" access to files in the
Fermilab central systems dcache:
1. Portal Access: Not supported.
Does not play well with automated transfers or future grid
development.
Work is not difficult to do (assuming portal code is available),
but is not salient to the department mission.
User can access other sites and acquire required credentials so no
one should be stopped by not have this. For trivial transfers, an
experimenter with no kerberos infrastructure can access some
portal node and move the data twice.
The work has unknown consequences for the software architecture.
Is there a Java API? Or are we going to have to use javah? The
department would rather put effort in to HRM + Grid FTP.
2. Strong Authentication: Reads and Writes Supported
a. User with kerberos credentials presents their kerberos
principle to the kerberos dcache ftp door.
b. Principle is verified with FNAL kdc. If bad, door exits.
c. The ftp server acquires the client's user name. There are
three possibilities by which this happens. All three
possibilities end with the server knowing the username. The
actual method depends on the implementation.
i. User explicitly sends ftp command "user ".
ii. User is prompted for their username and enters it.
iii. FTP client sends default username without the user
explicitly knowing about it.
Here is an example from Don Petravick that demonstrates that he
is prompted for his user name on node hppc:
hppc> type ftp
ftp is hashed (/fnal/ups/prd/kerberos/v1_3a/IRIX-6-5/./bin/ftp)
hppc> ftp
ftp> debug 1
Debugging on (debug=1).
ftp> open hppc.fnal.gov
Connected to hppc.fnal.gov.
220 hppc FTP server (Version 5.60) ready.
---> AUTH GSSAPI
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
Trying to authenticate to
calling gss_init_sec_context
---> ADAT
YIIB3QYJKoZIhvcSAQICAQBuggHMMIIByKADAgEFoQMCAQ6iBwMFACAAAACjggEQYYIBDDCCAQigAwIBBaEKGwhGTkFMLkdPVqIfMB2gAwIBA6EWMBQbA2Z0cBsNaHBwYy5mbmFsLmdvdqOB0zCB0KADAgEBoQMCAQKigcMEgc
BVmBByPWoUPtZ9LpoAY7CsR7jNdb8cZy/hqk4yJa+sR4lxOaWIc/b+ndPhKu2Ebf7VorWeirKcOEztV/MKo+LWYWYJin5gLsQXbAKxjWZLMojWFmn6eXAuVXSavgzdH4gMMs9X+gxtFHO6PSAZMZzQudUntfpndjcMGMrOwCAL
OnB2IUqHKWS2aJEgEPAeUgtXcSjhGt81rUeEKLr9asiragZwpqDxmeQCEfvixrfx58xFmR0eOPgtTDNPCxGCLkKkgZ4wgZugAwIBAaKBkwSBkEcnu8c2hODGMY8h42ic6S5iCq5KL6d7V8CHaZqe/nYjZ0xT4/kCP6HEQLMoiH
Nd8vPXSaUvasGR87HIizl9lGfkTJ7OzwZD7G8pP8Rtq9Mgvdfva0UauyRbY2SKBgN6x8AAke35UzT+ACEotcWIpBEBZzGUg2vzKBWQZpuL739E2676RhZMTcHxqtm1UfnFHQ==
calling gss_init_sec_context
GSSAPI authentication succeeded
Name (hppc.fnal.gov:petravic):
---> USER petravic
sealed (MIC) 61 bytes
secure_command(USER petravic)
encoding 84 bytes MIC
YDsGCSqGSIb3EgECAgIBAAD/////kUoURJnrGDP0FchcWYsE+vij+vXRGPaSVVNFUiBwZXRyYXZpYwACAg==
232 GSSAPI user petravic@FNAL.GOV is authorized as petravic
---> PWD
sealed (MIC) 53 bytes
secure_command(PWD)
encoding 72 bytes MIC
YDMGCSqGSIb3EgECAgIBAAD/////StgyRAExopxhZ4+ybfF5QGJwPGMwXgP7UFdEAAQEBAQ=
---> SYST
sealed (MIC) 53 bytes
secure_command(SYST)
encoding 72 bytes MIC
YDMGCSqGSIb3EgECAgIBAAD/////T9b3Vw1MrtXRZbE2K/GA1TOAZFFSBK5SU1lTVAADAwM=
215 UNIX Type: L8
Remote system type is UNIX.
Using binary mode to transfer files.
d. Door looks up username in its admin proxy file and determines
which kerberos principles are allowed to become username.
This is the same as .k5login files. It allows service
accounts. If principle is not allowed to become username,
door exits.
e. Door gets username's uid/gid from its admin proxy file and
checks the file's (or directory's for writes) user and group
permissions to see if the user is allowed to transfer the
file. If not, door exits.
f. Door transfers file to/from authenticated user.
3. Weak Authentication Write: Not supported.
Weak authentication means the user supplied a username to the
non-kerberized ftp door. A password is also supplied, but it is
not checked. This really means completely open access.
I think I went a bit overboard. We should check the password, it
is just that neither username with no password or username with
password are weak methods.
Arguments for supplying a clear text password are:
1) Users expect it.
2) We are better able to administer the system using the
analogous administrative acts for /etc/password files --
i.e. disable accounts by putting a special marker in the
password file.
3) For the (inevitable) cases where the username/password
pair get sniffed, we can deal with the user in the way they
expect - give them a "new password". That is much better
than "giving them a new user name", which is the
alternative.
Do not want to handle potential embarrassing problem where user
stores files with inappropriate names.
Support of weakly authenticated writes is fraught with problems.
The criteria is that even the namespace names of the files cannot
be seen via weak access. A naive implementation would not let a
person writing a file see the file through the namespace.
Consequently, people putting files in casually will be surprised
to not seem then in a "dir". People doing serious production
would likely be kerberized.
4. Weak Authentication Reads: Supported when experiment allows it.
See comments about weak authentication in item #3 above.
a. User is given a foreign uid/gid. Either one will be assigned
that as "foreign" or nobody/nobody is used.
b. Door checks its admin proxy file and determines if user's
file is in a directory subtree that is authorized by the
experiment for anonymous read access. By default, no
directories are authorized. If the directory is not
authorized, door exits.
c. Door checks file to see if experiment has set file's other
permission bits such that anonymous read access is allowed.
If not allowed, door exits.
d. Door transfers to anonymous user.