De los archivos de CIUB-L

      Sun, 9 Nov 1986 04:06:35 HOE

:     Llista Interna del ClUB <CIUB-L@EBOUBOll>

      Llista Interna del ClUB <CIUB-L@EBOUBOll>

      Jose Maria Blasco Comellas <ZCCBJBC@EBOUBOll>

      PACKAGE/FILELIST/SEE/NETLIST i NETSERV/NETINFO/LISTSERV/MISDISCOS


cribiendo una version bastante mejorada de SEE/PACKAGE. Podeis probarla

esta muy a trozos todavia) en el disco I con LKAT SERVERS  (O, si pedis

 el NETSERV FILELIST, con LKAT NETSERV). El nombre LKAT es provisional.


cipales ideas que quiero añadir son:


tura compatible (o casi compatible, como se vera)  con los filelists de

bsp;NETSERV  y  con los que  estan previstos  para NETINFO y LISTSERV  -   asi no

bsp;habra que aprenderse muchos formatos distintos de FILELIST.


fichero  lleva  asociados  dos  File  Authorization  Codes  (FAC),  que

bsp;determinan  quien  puede  acceder a  un  fichero y  quien esta  autorizado  a

bsp;modificarlo.  (P. ej,  un fichero podria ser  GET = CIUB,  PUT = Joan, Xavier

bsp;si se tratase de un paquete interno,  y GET = ALL,  PUT = Joan, JoseMaria, si

bsp;fuese, p.ej., una utilidad para usuarios en el disco G).


una vez habeis mirado el NETSERV FILELIST via BROWSE  (y aun mejor,  si

bsp;ademas  de haberlo hecho  habeis comparado  con NETLIST),  habreis visto  que

bsp;la informacion  que proporciona  es mas larga muchas veces  de lo que cabe en

bsp;una pantalla.  La idea es,  como NETLIST,  suprimir del display los FACs y el

bsp;filemode,  y permitir acceder a esa informacion  mediante una tecla FP  (La 6

bsp;en estos momentos).


cada filemode  (que es  transparente  para el usuario)  podra haber  un

bsp;Disk Access Code (DAC),  que indicara,  para cada filemode, el user y cuu del

bsp;poseedor del minidisco y  la password de lectura  (y posiblemente alguna cosa

bsp;mas; ya lo explicare cuando lo tenga mas claro). Por ejemplo, desde dentro de

bsp;LKAT SERVERS, que lista ficheros del disco I,  podeis hacer, despues de haber

bsp;probado  al menos  una vez el BROWSE,  REL I (DET,  y luego volver a intentar

bsp;BROWSE.  Vereis que  todavia funciona,  a pesar de que con Q DISK  podeis ver

bsp;que  el disco I  ya no lo teneis.  Esto es  porque hay  una  instruccion  que

bsp;define el disco I al principio del fichero SERVERS FILELIST.


bsp;[Si probais esto, no olvideis volver a acceder el disco I al final :-) ]


si un usuario intenta una operacion  (p. ej., BROWSE) sobre un fichero,

bsp;se mirara, en este orden:


bsp;- Si el FAC le autoriza a realizar la operacion  (es decir,  si esta incluido

bsp;  entre las  personas autorizadas  a acceder  este fichero).  Si no  lo esta,

bsp;  acceso denegado.  (Notad que esto *no* quiere decir que el usuario no pueda

bsp;  acceder por otros medios ajenos a LKAT  al fichero en cuestion;  es un tema

bsp;  de coherencia interna, pero no ofrece mucha proteccion real].


bsp;- Si el FAC le permite el acceso,  se mirara en los discos  ya accedidos para

bsp;  ver si figura el fichero buscado.  Si no es asi,  se ira al siguiente paso.

bsp;  Es posible que se realice tambien algun tipo  de comprobacion sobre fecha y

bsp;  hora, aunque esto todavia no lo tengo muy claro.


bsp;- Se mirara  si existe dentro del filelist  algun DAC que defina el 'filemode

bsp;  virtual' con que aparece el disco en el filelist.  Si es así,  se intentara

bsp;  el link y el access,  dando un mensaje de error  si hay algun fallo.  Notad

bsp;  que llamo  al filemode  con que  aparece  el fichero  dentro  del  filelist

bsp;  'virtual'.  Esto es porque solo funciona  como una referencia al DAC,  y no

bsp;  como un filemode real  (es decir,  puede ser que el disco  se acceda con un

bsp;  modo distinto al listado en el filelist  --  por ejemplo,  si el usuario ya

bsp;  tiene un disco con un tal modo).


bsp;- Finalmente,  si  no  existe  DAC en el fichero,  se mirara  en  un  fichero

bsp;  'useríd DAC'  para ver  si ahí si que existe un DAC correcto.  El proceso y

bsp;  los comentarios del parrafo anterior  tambien se aplican aquí.  Esta ultima

bsp;  posibilidad sirve  para que un fichero  (o un grupo de ficheros)  aparezcan

bsp;  en un  filelist  con GET = usuario  (o  usuarios)  y realmente nadie  pueda

bsp;  violar los FACs y acceder a un fichero  para el que no este autorizado,  ya

bsp;  que el filelist NO contendra el userid/cuu del disco.


ento  estoy escribiendo  el panel de visualizacion  (una especie de SEE

bsp;cuando opera en PACKAGES). Luego ya pensare el equivalente al PACKMAKE.


taria que os lo miraseis,  porque cuando este terminado,  si tiene buen

bsp;aspecto, me gustaria proponer que  TODOS LOS DISCOS NO ESTRICTAMENTE PRIVADOS

bsp;sean   mantenidos  via  FILELISTs.   Esto  se  podria  conseguir,   creo  yo,

bsp;permitiendo que  desde el panel  de edicion  se pudiese modificar  un fichero

bsp;o  añadir  otro  de  un modo  razonablemente  rapido.  Para  esto  se  podria

bsp;utilizar  un esquema similar  (pero automaticamente provisto por LKAT  o como

bsp;se  llame)  al MODIFG  (es el  exec  que utilizamos Juan,  Javier  y yo  para

bsp;mantener  el disco G  sin conflictos  tambien  el  ALD & co. tienen  algo que

bsp;ver).


deas !! Por favor !!


ia