De los archivos de CIUB-L

Date:         Sun, 9 Nov 1986 04:06:35 HOE
Reply-to:     Llista Interna del ClUB <CIUB-L@EBOUBOll>
Sender:       Llista Interna del ClUB <CIUB-L@EBOUBOll>
From:         Jose Maria Blasco Comellas <ZCCBJBC@EBOUBOll>
Subject:      PACKAGE/FILELIST/SEE/NETLIST i NETSERV/NETINFO/LISTSERV/MISDISCOS

Estoy escribiendo una version bastante mejorada de SEE/PACKAGE. Podeis probarla
(aunque esta muy a trozos todavia) en el disco I con LKAT SERVERS  (O, si pedis
o teneis el NETSERV FILELIST, con LKAT NETSERV). El nombre LKAT es provisional.

Las principales ideas que quiero añadir son:

* Estructura compatible (o casi compatible, como se vera)  con los filelists de
  NETSERV  y  con los que  estan previstos  para NETINFO y LISTSERV  -   asi no
  habra que aprenderse muchos formatos distintos de FILELIST.

* Cada  fichero  lleva  asociados  dos  File  Authorization  Codes  (FAC),  que
  determinan  quien  puede  acceder a  un  fichero y  quien esta  autorizado  a
  modificarlo.  (P. ej,  un fichero podria ser  GET = CIUB,  PUT = Joan, Xavier
  si se tratase de un paquete interno,  y GET = ALL,  PUT = Joan, JoseMaria, si
  fuese, p.ej., una utilidad para usuarios en el disco G).

* Si alguna vez habeis mirado el NETSERV FILELIST via BROWSE  (y aun mejor,  si
  ademas  de haberlo hecho  habeis comparado  con NETLIST),  habreis visto  que
  la informacion  que proporciona  es mas larga muchas veces  de lo que cabe en
  una pantalla.  La idea es,  como NETLIST,  suprimir del display los FACs y el
  filemode,  y permitir acceder a esa informacion  mediante una tecla FP  (La 6
  en estos momentos).

* Para  cada filemode  (que es  transparente  para el usuario)  podra haber  un
  Disk Access Code (DAC),  que indicara,  para cada filemode, el user y cuu del
  poseedor del minidisco y  la password de lectura  (y posiblemente alguna cosa
  mas; ya lo explicare cuando lo tenga mas claro). Por ejemplo, desde dentro de
  LKAT SERVERS, que lista ficheros del disco I,  podeis hacer, despues de haber
  probado  al menos  una vez el BROWSE,  REL I (DET,  y luego volver a intentar
  BROWSE.  Vereis que  todavia funciona,  a pesar de que con Q DISK  podeis ver
  que  el disco I  ya no lo teneis.  Esto es  porque hay  una  instruccion  que
  define el disco I al principio del fichero SERVERS FILELIST.

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

* Asi,  si un usuario intenta una operacion  (p. ej., BROWSE) sobre un fichero,
  se mirara, en este orden:

  - Si el FAC le autoriza a realizar la operacion  (es decir,  si esta incluido
    entre las  personas autorizadas  a acceder  este fichero).  Si no  lo esta,
    acceso denegado.  (Notad que esto *no* quiere decir que el usuario no pueda
    acceder por otros medios ajenos a LKAT  al fichero en cuestion;  es un tema
    de coherencia interna, pero no ofrece mucha proteccion real].

  - Si el FAC le permite el acceso,  se mirara en los discos  ya accedidos para
    ver si figura el fichero buscado.  Si no es asi,  se ira al siguiente paso.
    Es posible que se realice tambien algun tipo  de comprobacion sobre fecha y
    hora, aunque esto todavia no lo tengo muy claro.

  - Se mirara  si existe dentro del filelist  algun DAC que defina el 'filemode
    virtual' con que aparece el disco en el filelist.  Si es así,  se intentara
    el link y el access,  dando un mensaje de error  si hay algun fallo.  Notad
    que llamo  al filemode  con que  aparece  el fichero  dentro  del  filelist
    'virtual'.  Esto es porque solo funciona  como una referencia al DAC,  y no
    como un filemode real  (es decir,  puede ser que el disco  se acceda con un
    modo distinto al listado en el filelist  --  por ejemplo,  si el usuario ya
    tiene un disco con un tal modo).

  - Finalmente,  si  no  existe  DAC en el fichero,  se mirara  en  un  fichero
    'useríd DAC'  para ver  si ahí si que existe un DAC correcto.  El proceso y
    los comentarios del parrafo anterior  tambien se aplican aquí.  Esta ultima
    posibilidad sirve  para que un fichero  (o un grupo de ficheros)  aparezcan
    en un  filelist  con GET = usuario  (o  usuarios)  y realmente nadie  pueda
    violar los FACs y acceder a un fichero  para el que no este autorizado,  ya
    que el filelist NO contendra el userid/cuu del disco.

* De momento  estoy escribiendo  el panel de visualizacion  (una especie de SEE
  cuando opera en PACKAGES). Luego ya pensare el equivalente al PACKMAKE.

* Me gustaria que os lo miraseis,  porque cuando este terminado,  si tiene buen
  aspecto, me gustaria proponer que  TODOS LOS DISCOS NO ESTRICTAMENTE PRIVADOS
  sean   mantenidos  via  FILELISTs.   Esto  se  podria  conseguir,   creo  yo,
  permitiendo que  desde el panel  de edicion  se pudiese modificar  un fichero
  o  añadir  otro  de  un modo  razonablemente  rapido.  Para  esto  se  podria
  utilizar  un esquema similar  (pero automaticamente provisto por LKAT  o como
  se  llame)  al MODIFG  (es el  exec  que utilizamos Juan,  Javier  y yo  para
  mantener  el disco G  sin conflictos  tambien  el  ALD & co. tienen  algo que
  ver).

Ideas, ideas !! Por favor !!

Jose Maria