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.