Re: Seguridad en tablas

La cuestion es la siguiente, en mi empresa tenemos un aplicativo en
access 2000 para trabajos de digitación, la base de datos principal
esta en PostgreSQL. En estos dias detallamos que empleados maliciosos
vinculan las tablas desde access para modificar directamente las
tablas y asi violar la privacidad de la informacion y beneficiarse
ellos mismos para incrementar su nivel de produccion, alguien sabe
como impedir que esto suceda sin afectar el trabajo de digitacion,
recordando que estos villanos son los que alimentan la base de datos
por lo que no se les puede quitar los permisos de agregar y modificar
dicha informacion, espero que esto sea claro , Graciassss al quien me
pueda guiar y convatir a estos delicuentes.

On 01/12/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> La cuestion es la siguiente, en mi empresa tenemos un aplicativo en
> access 2000 para trabajos de digitación, la base de datos principal
> esta en PostgreSQL. En estos dias detallamos que empleados maliciosos
> vinculan las tablas desde access para modificar directamente las
> tablas y asi violar la privacidad de la informacion y beneficiarse

A ver si entiendo.... tus trabajadores hicieron algun cambio en la
aplicacion que usan para digitalizar lo cual resulto en un aumento de
la produccion, entonces... cual es el problema?

> ellos mismos para incrementar su nivel de produccion, alguien sabe
> como impedir que esto suceda sin afectar el trabajo de digitacion,
> recordando que estos villanos son los que alimentan la base de datos
> por lo que no se les puede quitar los permisos de agregar y modificar
> dicha informacion, espero que esto sea claro , Graciassss al quien me
> pueda guiar y convatir a estos delicuentes.
>
>

No se entiende mucho que es lo que quieres.

Pero si una persona está a cargo de una empresa lo que busca es que
los empleados tengan un mayor nivel de producción o ¿me equivoco?

entonces estono sería un problema
El 1/12/05, Andres Ortiz<ing(dot)andresortiz(at)gmail(dot)com> escribió:
> La cuestion es la siguiente, en mi empresa tenemos un aplicativo en
> access 2000 para trabajos de digitación, la base de datos principal
> esta en PostgreSQL. En estos dias detallamos que empleados maliciosos
> vinculan las tablas desde access para modificar directamente las
> tablas y asi violar la privacidad de la informacion y beneficiarse
> ellos mismos para incrementar su nivel de produccion, alguien sabe
> como impedir que esto suceda sin afectar el trabajo de digitacion,
> recordando que estos villanos son los que alimentan la base de datos
> por lo que no se les puede quitar los permisos de agregar y modificar
> dicha informacion, espero que esto sea claro , Graciassss al quien me
> pueda guiar y convatir a estos delicuentes.
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 10: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>

Jaime Casanova <systemguards(at)gmail(dot)com> writes:

> imagino que asi es el problema de Andres... sin embargo como lograr
> que tengas permisos de escritura y a la vez que no puedan hacer eso?

Una combinación de vistas y reglas harían el trabajo.

Saludos,
Manuel.

> entonces estono sería un problema
> El 1/12/05, Andres Ortiz<ing(dot)andresortiz(at)gmail(dot)com> escribió:
> > La cuestion es la siguiente, en mi empresa tenemos un aplicativo en
> > access 2000 para trabajos de digitación, la base de datos principal
> > esta en PostgreSQL. En estos dias detallamos que empleados maliciosos
> > vinculan las tablas desde access para modificar directamente las
> > tablas y asi violar la privacidad de la informacion y beneficiarse
> > ellos mismos para incrementar su nivel de produccion, alguien sabe
> > como impedir que esto suceda sin afectar el trabajo de digitacion,
> > recordando que estos villanos son los que alimentan la base de datos
> > por lo que no se les puede quitar los permisos de agregar y modificar
> > dicha informacion, espero que esto sea claro , Graciassss al quien me
> > pueda guiar y convatir a estos delicuentes.
> >

On 12/1/05, Rommel Oramas <rommel(dot)oramas(at)gmail(dot)com> wrote:
> No se entiende mucho que es lo que quieres.
>
> Pero si una persona está a cargo de una empresa lo que busca es que
> los empleados tengan un mayor nivel de producción o ¿me equivoco?
>

Seria un problema si el nivel de produccion es falso... pongamos por
ejemplo un vendedor que modifica registros para que parezca que ventas
de otros vendedores las a hecho el...

imagino que asi es el problema de Andres... sin embargo como lograr
que tengas permisos de escritura y a la vez que no puedan hacer eso?

--
Atentamente,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

Jaime Casanova <systemguards(at)gmail(dot)com> writes:

> Seguro? de que forma ayudaria? debe permitirme hacer los mismo inserts
> y/o updates a la base...

Si seguro. Dime la tabla y las columnas que quieres protejer y te doy
la vista y las reglas.

Saludos,
Manuel.

On 12/1/05, Manuel Sugawara <masm(at)fciencias(dot)unam(dot)mx> wrote:
> Jaime Casanova <systemguards(at)gmail(dot)com> writes:
>
> > imagino que asi es el problema de Andres... sin embargo como lograr
> > que tengas permisos de escritura y a la vez que no puedan hacer eso?
>
> Una combinación de vistas y reglas harían el trabajo.
>
> Saludos,
> Manuel.
>

Seguro? de que forma ayudaria? debe permitirme hacer los mismo inserts
y/o updates a la base...

--
Atentamente,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

Holas, se me ocurren algunas cosas que te voy a mencionar

Tienes una base de datos que esta en Postgre esta es accedida por los
usuarios por medio de un cliente que esta en Access.

1.- Imagino que en Access tienes implementado formularios para el acceso a
los datos.
2.- Los usuarios no tienen acceso directo a las tablas.
3.- Los usuarios desconocen la clave de acceso a Postgre.
4.- La aplicación les pide una clave de acceso los cuales no son usuarios
reales de la bd.

Si con todo esto = logran modificar los datos, como mencionas reasignarse
una venta que no les corresponde y probablemente lo hagan por que pueden
modificar ese dato, genera un histórico.
Si alguien modifica una venta marcas eliminas el registro en forma lógica y
creas uno nuevo con los datos actuales, posteriormente puedes hacer una
auditoria.

De todas formas seria bueno tener privilegios de acceso, un cambio de ese
tipo debe requerir un permiso de supervisor o algo similar.

Hay que partir de una primicia, todos tienen acceso a google, por lo tanto
los “secretos” no están reservados para informáticos. A buen entendedor…

Espero que te sirva…

-----Mensaje original-----
De: pgsql-es-ayuda-owner(at)postgresql(dot)org
[mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org] En nombre de Andres Ortiz
Enviado el: 01-12-2005 18:50
Para: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: [pgsql-es-ayuda] Seguridad en tablas

La cuestion es la siguiente, en mi empresa tenemos un aplicativo en
access 2000 para trabajos de digitación, la base de datos principal
esta en PostgreSQL. En estos dias detallamos que empleados maliciosos
vinculan las tablas desde access para modificar directamente las
tablas y asi violar la privacidad de la informacion y beneficiarse
ellos mismos para incrementar su nivel de produccion, alguien sabe
como impedir que esto suceda sin afectar el trabajo de digitacion,
recordando que estos villanos son los que alimentan la base de datos
por lo que no se les puede quitar los permisos de agregar y modificar
dicha informacion, espero que esto sea claro , Graciassss al quien me
pueda guiar y convatir a estos delicuentes.

---------------------------(fin del mensaje)---------------------------
TIP 10: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

On 02/12/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> No, la aplicacion esta intacta, lo que hacen es vincular tablas que
> estan alojadas en la base de datos principal y modificar el nombre de
> usuario que trabajo un lote de informacion por otro, logrando quitarle
> produccion a otro empleado para incluir su nombre de usuario y asi
> lograr tener un mayor volumen de produccion individual, aqui en la
> empresa los digitadores son evaluados por produccion y rendimiento,
> por lo que decimos que tenemos sanguijuelas dentro de nuestra
> compañia. Espero aclarar esta situacion, y obtener una guia al
> respecto. Graciasss.
>
Please, no envies privados sobre este tema. Reenvio a la lista.

>
> El 1/12/05, Mario Gonzalez<gonzalemario(at)gmail(dot)com> escribió:
> > On 01/12/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > > La cuestion es la siguiente, en mi empresa tenemos un aplicativo en
> > > access 2000 para trabajos de digitación, la base de datos principal
> > > esta en PostgreSQL. En estos dias detallamos que empleados maliciosos
> > > vinculan las tablas desde access para modificar directamente las
> > > tablas y asi violar la privacidad de la informacion y beneficiarse
> >
> > A ver si entiendo.... tus trabajadores hicieron algun cambio en la
> > aplicacion que usan para digitalizar lo cual resulto en un aumento de
> > la produccion, entonces... cual es el problema?
> >
> > > ellos mismos para incrementar su nivel de produccion, alguien sabe
> > > como impedir que esto suceda sin afectar el trabajo de digitacion,
> > > recordando que estos villanos son los que alimentan la base de datos
> > > por lo que no se les puede quitar los permisos de agregar y modificar
> > > dicha informacion, espero que esto sea claro , Graciassss al quien me
> > > pueda guiar y convatir a estos delicuentes.
> > >
> > >
> >
>

Respondí a la lista por si no sabes leer, no me fije que estabas en la
copia.
Y si tienen acceso a la bd esta claro donde esta el problema.

-----Mensaje original-----
De: pgsql-es-ayuda-owner(at)postgresql(dot)org
[mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org] En nombre de Mario Gonzalez
Enviado el: 02-12-2005 10:42
Para: Andres Ortiz; lista de ayuda Postgres
Asunto: Re: [pgsql-es-ayuda] Seguridad en tablas

On 02/12/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> No, la aplicacion esta intacta, lo que hacen es vincular tablas que
> estan alojadas en la base de datos principal y modificar el nombre de
> usuario que trabajo un lote de informacion por otro, logrando quitarle
> produccion a otro empleado para incluir su nombre de usuario y asi
> lograr tener un mayor volumen de produccion individual, aqui en la
> empresa los digitadores son evaluados por produccion y rendimiento,
> por lo que decimos que tenemos sanguijuelas dentro de nuestra
> compañia. Espero aclarar esta situacion, y obtener una guia al
> respecto. Graciasss.
>
Please, no envies privados sobre este tema. Reenvio a la lista.

>
> El 1/12/05, Mario Gonzalez<gonzalemario(at)gmail(dot)com> escribió:
> > On 01/12/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > > La cuestion es la siguiente, en mi empresa tenemos un aplicativo en
> > > access 2000 para trabajos de digitación, la base de datos principal
> > > esta en PostgreSQL. En estos dias detallamos que empleados maliciosos
> > > vinculan las tablas desde access para modificar directamente las
> > > tablas y asi violar la privacidad de la informacion y beneficiarse
> >
> > A ver si entiendo.... tus trabajadores hicieron algun cambio en la
> > aplicacion que usan para digitalizar lo cual resulto en un aumento de
> > la produccion, entonces... cual es el problema?
> >
> > > ellos mismos para incrementar su nivel de produccion, alguien sabe
> > > como impedir que esto suceda sin afectar el trabajo de digitacion,
> > > recordando que estos villanos son los que alimentan la base de datos
> > > por lo que no se les puede quitar los permisos de agregar y modificar
> > > dicha informacion, espero que esto sea claro , Graciassss al quien me
> > > pueda guiar y convatir a estos delicuentes.
> > >
> > >
> >
>

---------------------------(fin del mensaje)---------------------------
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envíe "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)

On 12/1/05, Manuel Sugawara <masm(at)fciencias(dot)unam(dot)mx> wrote:
> Jaime Casanova <systemguards(at)gmail(dot)com> writes:
>
> > Seguro? de que forma ayudaria? debe permitirme hacer los mismo inserts
> > y/o updates a la base...
>
> Si seguro. Dime la tabla y las columnas que quieres protejer y te doy
> la vista y las reglas.
>
> Saludos,
> Manuel.
>

Haber Manuel, pensando en el problema de Andres veamos como protejer
esta tabla...

create table LOTE_PRODUCCION (
codigo serial not null primary key,
cod_digitador integer not null references DIGITADOR(codigo),
-- asumo que lo que van a digitar esta divido en bloques o lotes y que
para mayor
-- comodidad han sido debidamente numerados
numero_lote integer not null,
fecha_inicio timestamp not null,
fecha_fin timestamp
);

--
Atentamente,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

No. Al parecer ellos se modificaron manualmente las horas prodicidas no fue
q aumentaron la productividad sino que hicieron fraude, cambiaron los datos.
Tu problema basico creo es de tu front no PostgreSQL

*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-747-2787
* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo
comun"
*-------------------------------------------------------*

>From: Rommel Oramas <rommel(dot)oramas(at)gmail(dot)com>
>To: Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com>
>CC: pgsql-es-ayuda(at)postgresql(dot)org
>Subject: Re: [pgsql-es-ayuda] Seguridad en tablas
>Date: Thu, 1 Dec 2005 17:25:18 -0500
>
>No se entiende mucho que es lo que quieres.
>
>Pero si una persona está a cargo de una empresa lo que busca es que
>los empleados tengan un mayor nivel de producción o ¿me equivoco?
>
>entonces estono sería un problema
>El 1/12/05, Andres Ortiz<ing(dot)andresortiz(at)gmail(dot)com> escribió:
> > La cuestion es la siguiente, en mi empresa tenemos un aplicativo en
> > access 2000 para trabajos de digitación, la base de datos principal
> > esta en PostgreSQL. En estos dias detallamos que empleados maliciosos
> > vinculan las tablas desde access para modificar directamente las
> > tablas y asi violar la privacidad de la informacion y beneficiarse
> > ellos mismos para incrementar su nivel de produccion, alguien sabe
> > como impedir que esto suceda sin afectar el trabajo de digitacion,
> > recordando que estos villanos son los que alimentan la base de datos
> > por lo que no se les puede quitar los permisos de agregar y modificar
> > dicha informacion, espero que esto sea claro , Graciassss al quien me
> > pueda guiar y convatir a estos delicuentes.
> >
> > ---------------------------(fin del mensaje)---------------------------
> > TIP 10: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
> >
>
>---------------------------(fin del mensaje)---------------------------
>TIP 10: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

_________________________________________________________________
Visita MSN Latino Entretenimiento: ¡música, cine, chismes, TV y más...!
http://latino.msn.com/entretenimiento/

On 02/12/05, Roman Jesus Astorga Guzman <roman_astorga(at)hotmail(dot)com> wrote:
>
>
> Respondí a la lista por si no sabes leer,

Por favor, no son necesarios los insultos ni el habla ironica para
entablar una conversacion. Un poco de modales o respeto no estaria
para nada mal.

>no me fije que estabas en la
> copia.
> Y si tienen acceso a la bd esta claro donde esta el problema.
>
> -----Mensaje original-----
> De: pgsql-es-ayuda-owner(at)postgresql(dot)org
> [mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org] En nombre de Mario Gonzalez
> Enviado el: 02-12-2005 10:42
> Para: Andres Ortiz; lista de ayuda Postgres
> Asunto: Re: [pgsql-es-ayuda] Seguridad en tablas
>
> On 02/12/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > No, la aplicacion esta intacta, lo que hacen es vincular tablas que
> > estan alojadas en la base de datos principal y modificar el nombre de
> > usuario que trabajo un lote de informacion por otro, logrando quitarle
> > produccion a otro empleado para incluir su nombre de usuario y asi
> > lograr tener un mayor volumen de produccion individual, aqui en la
> > empresa los digitadores son evaluados por produccion y rendimiento,
> > por lo que decimos que tenemos sanguijuelas dentro de nuestra
> > compañia. Espero aclarar esta situacion, y obtener una guia al
> > respecto. Graciasss.
> >
> Please, no envies privados sobre este tema. Reenvio a la lista.
>
> >
> > El 1/12/05, Mario Gonzalez<gonzalemario(at)gmail(dot)com> escribió:
> > > On 01/12/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > > > La cuestion es la siguiente, en mi empresa tenemos un aplicativo en

[...]

Jaime Casanova escribió:

> Haber Manuel, pensando en el problema de Andres veamos como protejer
> esta tabla...
>
> create table LOTE_PRODUCCION (
> codigo serial not null primary key,
> cod_digitador integer not null references DIGITADOR(codigo),
> -- asumo que lo que van a digitar esta divido en bloques o lotes y que
> para mayor
> -- comodidad han sido debidamente numerados
> numero_lote integer not null,
> fecha_inicio timestamp not null,
> fecha_fin timestamp
> );

Falta especificar las columnas que se quiere proteger. La idea es
determinar exactamente: que pueden hacer los operadores con la tabla?

Si la idea es que solo puedan ingresar registros, entonces la solucion
es mucho mas facil: simplemente dale privilegios INSERT y quitales los
privilegios UPDATE y DELETE.

Ahora, si la idea es que puedan ingresar registros y tambien cambiar
otros, entonces, como decia Manuel, vas a tener que definir una vista
que tenga una regla ON UPDATE que permita hacer solo las modificaciones
que correspondan. Pero claro, tienes que especificar cuales son las
modificaciones aceptables y cuales no lo son!

Ahora, si el problema es que los digitadores deben tener privilegios
para modificar algun determinado campo, y haciendo uso de ese
privilegio ellos pueden ingresar datos fraudulentos, entonces el
problema es que no has definido las restricciones de privilegios con la
suficiente granularidad -- en tal caso, estas de vuelta en el pizarron
junto con Bart Simpson.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

El unico campo que me interesa proteger es el que tiene el nombre de
usuario, y si hay alguna manera de que al vincular las tablas de
PostgreSQL via ODBC en Access no me lo permita o necesite de un
usuario o contraseña para logralo.

El 2/12/05, Alvaro Herrera<alvherre(at)commandprompt(dot)com> escribió:
> Jaime Casanova escribió:
>
> > Haber Manuel, pensando en el problema de Andres veamos como protejer
> > esta tabla...
> >
> > create table LOTE_PRODUCCION (
> > codigo serial not null primary key,
> > cod_digitador integer not null references DIGITADOR(codigo),
> > -- asumo que lo que van a digitar esta divido en bloques o lotes y que
> > para mayor
> > -- comodidad han sido debidamente numerados
> > numero_lote integer not null,
> > fecha_inicio timestamp not null,
> > fecha_fin timestamp
> > );
>
> Falta especificar las columnas que se quiere proteger. La idea es
> determinar exactamente: que pueden hacer los operadores con la tabla?
>
> Si la idea es que solo puedan ingresar registros, entonces la solucion
> es mucho mas facil: simplemente dale privilegios INSERT y quitales los
> privilegios UPDATE y DELETE.
>
> Ahora, si la idea es que puedan ingresar registros y tambien cambiar
> otros, entonces, como decia Manuel, vas a tener que definir una vista
> que tenga una regla ON UPDATE que permita hacer solo las modificaciones
> que correspondan. Pero claro, tienes que especificar cuales son las
> modificaciones aceptables y cuales no lo son!
>
> Ahora, si el problema es que los digitadores deben tener privilegios
> para modificar algun determinado campo, y haciendo uso de ese
> privilegio ellos pueden ingresar datos fraudulentos, entonces el
> problema es que no has definido las restricciones de privilegios con la
> suficiente granularidad -- en tal caso, estas de vuelta en el pizarron
> junto con Bart Simpson.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

<Limpiando... borrando conversaciones enredadas>

On 12/2/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> El unico campo que me interesa proteger es el que tiene el nombre de
> usuario, y si hay alguna manera de que al vincular las tablas de
> PostgreSQL via ODBC en Access no me lo permita o necesite de un
> usuario o contraseña para logralo.
>

OK Andres, Manuel y Alvaro tienen toda la razon (al parecer algo se
enredo en mi cerebro y no me dejo pensar claramente, seria PHP?)...

Aunque Alvaro y Manuel aconsejan que crees una vista yo solo crearia
una nueva tabla y una regla, algo asi:

CREATE TABLE sanguijuelas (
usuario tipo_dato not null
);

CREATE RULE no_a_las_sanguijuelas AS ON UPDATE TO tabla
WHERE NEW.usuario <> OLD.usuario
DO INSTEAD INSERT INTO sanguijuelas VALUES (NEW.usuario);

Con la regla evitas que modifiquen la tabla cuando el cambio que hacen
incluye cambiar el usuario y ademas dejas un registro de que usuario
quizo hacer eso en la tabla sanguijuelas.

--
Atentamente,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

Exelente idea la que me acabas de decir, se me olvido comertar que soy
algo nuevo en esto del PostgreSql, no conocia la existencia de reglas,
pero ya mismo indago sobre la creacion de reglas, agradezco abusando
de tus conocimientos, que me pudieras regalar donde encuentro el
registro de que usuario quizo meterme el gol con esto del fraude para
mas adelante tomar medidas drasticas. De verdad te agradesco muchisimo
esta solucion y to te imaginas del embrollo que me acabas de sacar,
cualquier problema con Php con gusto te colaboro.

El 2/12/05, Jaime Casanova<systemguards(at)gmail(dot)com> escribió:
> <Limpiando... borrando conversaciones enredadas>
>
> On 12/2/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > El unico campo que me interesa proteger es el que tiene el nombre de
> > usuario, y si hay alguna manera de que al vincular las tablas de
> > PostgreSQL via ODBC en Access no me lo permita o necesite de un
> > usuario o contraseña para logralo.
> >
>
> OK Andres, Manuel y Alvaro tienen toda la razon (al parecer algo se
> enredo en mi cerebro y no me dejo pensar claramente, seria PHP?)...
>
> Aunque Alvaro y Manuel aconsejan que crees una vista yo solo crearia
> una nueva tabla y una regla, algo asi:
>
> CREATE TABLE sanguijuelas (
> usuario tipo_dato not null
> );
>
>
> CREATE RULE no_a_las_sanguijuelas AS ON UPDATE TO tabla
> WHERE NEW.usuario <> OLD.usuario
> DO INSTEAD INSERT INTO sanguijuelas VALUES (NEW.usuario);
>
>
> Con la regla evitas que modifiquen la tabla cuando el cambio que hacen
> incluye cambiar el usuario y ademas dejas un registro de que usuario
> quizo hacer eso en la tabla sanguijuelas.
>
>
> --
> Atentamente,
> Jaime Casanova
> (DBA: DataBase Aniquilator ;)
>

Jaime Casanova <systemguards(at)gmail(dot)com> writes:

> Haber Manuel, pensando en el problema de Andres veamos como protejer
> esta tabla...

Creo que llegue un poco tarde a la conversación pero la idea es que la
regla ON UPDATE explicitamente ignore los campos que quieres protejer,
por ejemplo, si haces una vista lote_producción_view entonces la regla
sería:

create rule lote_producción_upd as on update on lote_producción_view
do instead update lote_producción numero_lote = new.numero,
fecha_inicio = new.fecha_inicio,
fecha_fin = new.fecha_fin
where codigo = new.codigo;

Nota que no se podría actualizar cod_digitador ya que la regla lo
impide.

Saludos,
Manuel.

> El 2/12/05, Jaime Casanova<systemguards(at)gmail(dot)com> escribió:
> > <Limpiando... borrando conversaciones enredadas>
> >
> > On 12/2/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > > El unico campo que me interesa proteger es el que tiene el nombre de
> > > usuario, y si hay alguna manera de que al vincular las tablas de
> > > PostgreSQL via ODBC en Access no me lo permita o necesite de un
> > > usuario o contraseña para logralo.
> > >
> >
> > OK Andres, Manuel y Alvaro tienen toda la razon (al parecer algo se
> > enredo en mi cerebro y no me dejo pensar claramente, seria PHP?)...
> >
> > Aunque Alvaro y Manuel aconsejan que crees una vista yo solo crearia
> > una nueva tabla y una regla, algo asi:
> >
> > CREATE TABLE sanguijuelas (
> > usuario tipo_dato not null
> > );
> >
> >
> > CREATE RULE no_a_las_sanguijuelas AS ON UPDATE TO tabla
> > WHERE NEW.usuario <> OLD.usuario
> > DO INSTEAD INSERT INTO sanguijuelas VALUES (NEW.usuario);
> >
> >
> > Con la regla evitas que modifiquen la tabla cuando el cambio que hacen
> > incluye cambiar el usuario y ademas dejas un registro de que usuario
> > quizo hacer eso en la tabla sanguijuelas.
> >
> >
On 12/2/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> Exelente idea la que me acabas de decir, se me olvido comertar que soy
> algo nuevo en esto del PostgreSql, no conocia la existencia de reglas,
> pero ya mismo indago sobre la creacion de reglas, agradezco abusando
> de tus conocimientos, que me pudieras regalar donde encuentro el
> registro de que usuario quizo meterme el gol con esto del fraude para
> mas adelante tomar medidas drasticas. De verdad te agradesco muchisimo
> esta solucion y to te imaginas del embrollo que me acabas de sacar,
> cualquier problema con Php con gusto te colaboro.
>

en la tabla sanguijuelas que te puse ahi... se va a crear un registro
cada vez que un usuario intente modificar el campo, incluso puedes
añadir un campo fecha para indicar en que momento intentaron hacer el
cambio y hasta podrias añadir para la direccion ip de la maquina
(aunque no recuerdo la funcion que regresa la ip de la maquina
cliente)

CREATE TABLE sanguijuelas (
usuario tipo_dato not null,
fecha timestamp not null
);

CREATE RULE no_a_las_sanguijuelas AS ON UPDATE TO tabla
WHERE NEW.usuario <> OLD.usuario
DO INSTEAD
INSERT INTO sanguijuelas VALUES (NEW.usuario, current_timestamp);

--
Atentamente,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

Listo Jaime, andaba perdido pero ya entendí la idea que planteaste y la puse
en practica, funciona perfectamente y aquí todos los ingenieros que en la
mayoría somos jóvenes recién egresados estamos anonadados con la facilidad
que se logro revolver esta situación de agujero de seguridad que teniamos,
una vez mas te agradezco muchísimo por tu colaboración y ya estamos
trabajando para perfeccionar tu sugerencia que al final termino salvándonos
el pellejo.

Graciasss.
Andres Ortiz
Imagine Technologies
Bogotá (Colombia)

El día 2/12/05, Jaime Casanova <systemguards(at)gmail(dot)com> escribió:
>
> > El 2/12/05, Jaime Casanova<systemguards(at)gmail(dot)com> escribió:
> > > <Limpiando... borrando conversaciones enredadas>
> > >
> > > On 12/2/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > > > El unico campo que me interesa proteger es el que tiene el nombre de
> > > > usuario, y si hay alguna manera de que al vincular las tablas de
> > > > PostgreSQL via ODBC en Access no me lo permita o necesite de un
> > > > usuario o contraseña para logralo.
> > > >
> > >
> > > OK Andres, Manuel y Alvaro tienen toda la razon (al parecer algo se
> > > enredo en mi cerebro y no me dejo pensar claramente, seria PHP?)...
> > >
> > > Aunque Alvaro y Manuel aconsejan que crees una vista yo solo crearia
> > > una nueva tabla y una regla, algo asi:
> > >
> > > CREATE TABLE sanguijuelas (
> > > usuario tipo_dato not null
> > > );
> > >
> > >
> > > CREATE RULE no_a_las_sanguijuelas AS ON UPDATE TO tabla
> > > WHERE NEW.usuario <> OLD.usuario
> > > DO INSTEAD INSERT INTO sanguijuelas VALUES (NEW.usuario);
> > >
> > >
> > > Con la regla evitas que modifiquen la tabla cuando el cambio que hacen
> > > incluye cambiar el usuario y ademas dejas un registro de que usuario
> > > quizo hacer eso en la tabla sanguijuelas.
> > >
> > >
> On 12/2/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > Exelente idea la que me acabas de decir, se me olvido comertar que soy
> > algo nuevo en esto del PostgreSql, no conocia la existencia de reglas,
> > pero ya mismo indago sobre la creacion de reglas, agradezco abusando
> > de tus conocimientos, que me pudieras regalar donde encuentro el
> > registro de que usuario quizo meterme el gol con esto del fraude para
> > mas adelante tomar medidas drasticas. De verdad te agradesco muchisimo
> > esta solucion y to te imaginas del embrollo que me acabas de sacar,
> > cualquier problema con Php con gusto te colaboro.
> >
>
> en la tabla sanguijuelas que te puse ahi... se va a crear un registro
> cada vez que un usuario intente modificar el campo, incluso puedes
> añadir un campo fecha para indicar en que momento intentaron hacer el
> cambio y hasta podrias añadir para la direccion ip de la maquina
> (aunque no recuerdo la funcion que regresa la ip de la maquina
> cliente)
>
> CREATE TABLE sanguijuelas (
> usuario tipo_dato not null,
> fecha timestamp not null
> );
>
> CREATE RULE no_a_las_sanguijuelas AS ON UPDATE TO tabla
> WHERE NEW.usuario <> OLD.usuario
> DO INSTEAD
> INSERT INTO sanguijuelas VALUES (NEW.usuario, current_timestamp);
>
>
> --
> Atentamente,
> Jaime Casanova
> (DBA: DataBase Aniquilator ;)
>

Disculpen el top pop, pero no seria mucho mejor tener un trigger y
dejar que el usuario cambie la información, cosa que el trigger genere
dos cosas, guardar el valor antiguo o modificado o incluso borrado, el
nombre del personaje que lo cambio, y por supuesto el IP (ideal
tambien el time stamp de la modificación),esto no evita que se
modifique el dato, por el contrario deja todo tal cual, pero permite
colgar al perico que modifico el dato, esto me a dado resultados.

Ojo, no estoy diciendo que no arreglen el modelo de trabajo, flujo
grama o las reglas del negocio, sino que aprovechen el hecho que la
base esta abierta y auditen a los pericos maliciosos.

El 2/12/05, Andres Ortiz<ing(dot)andresortiz(at)gmail(dot)com> escribió:
> Listo Jaime, andaba perdido pero ya entendí la idea que planteaste y la puse
> en practica, funciona perfectamente y aquí todos los ingenieros que en la
> mayoría somos jóvenes recién egresados estamos anonadados con la facilidad
> que se logro revolver esta situación de agujero de seguridad que teniamos,
> una vez mas te agradezco muchísimo por tu colaboración y ya estamos
> trabajando para perfeccionar tu sugerencia que al final termino salvándonos
> el pellejo.
>
> Graciasss.
> Andres Ortiz
> Imagine Technologies
> Bogotá (Colombia)
>
>
> El día 2/12/05, Jaime Casanova <systemguards(at)gmail(dot)com> escribió:
> > > El 2/12/05, Jaime Casanova<systemguards(at)gmail(dot)com> escribió:
> > > > <Limpiando... borrando conversaciones enredadas>
> > > >
> > > > On 12/2/05, Andres Ortiz <ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > > > > El unico campo que me interesa proteger es el que tiene el nombre de
> > > > > usuario, y si hay alguna manera de que al vincular las tablas de
> > > > > PostgreSQL via ODBC en Access no me lo permita o necesite de un
> > > > > usuario o contraseña para logralo.
> > > > >
> > > >
> > > > OK Andres, Manuel y Alvaro tienen toda la razon (al parecer algo se
> > > > enredo en mi cerebro y no me dejo pensar claramente, seria PHP?)...
> > > >
> > > > Aunque Alvaro y Manuel aconsejan que crees una vista yo solo crearia
> > > > una nueva tabla y una regla, algo asi:
> > > >
> > > > CREATE TABLE sanguijuelas (
> > > > usuario tipo_dato not null
> > > > );
> > > >
> > > >
> > > > CREATE RULE no_a_las_sanguijuelas AS ON UPDATE TO tabla
> > > > WHERE NEW.usuario <> OLD.usuario
> > > > DO INSTEAD INSERT INTO sanguijuelas VALUES (NEW.usuario);
> > > >
> > > >
> > > > Con la regla evitas que modifiquen la tabla cuando el cambio que hacen
> > > > incluye cambiar el usuario y ademas dejas un registro de que usuario
> > > > quizo hacer eso en la tabla sanguijuelas.
> > > >
> > > >
> > On 12/2/05, Andres Ortiz < ing(dot)andresortiz(at)gmail(dot)com> wrote:
> > > Exelente idea la que me acabas de decir, se me olvido comertar que soy
> > > algo nuevo en esto del PostgreSql, no conocia la existencia de reglas,
> > > pero ya mismo indago sobre la creacion de reglas, agradezco abusando
> > > de tus conocimientos, que me pudieras regalar donde encuentro el
> > > registro de que usuario quizo meterme el gol con esto del fraude para
> > > mas adelante tomar medidas drasticas. De verdad te agradesco muchisimo
> > > esta solucion y to te imaginas del embrollo que me acabas de sacar,
> > > cualquier problema con Php con gusto te colaboro.
> > >
> >
> > en la tabla sanguijuelas que te puse ahi... se va a crear un registro
> > cada vez que un usuario intente modificar el campo, incluso puedes
> > añadir un campo fecha para indicar en que momento intentaron hacer el
> > cambio y hasta podrias añadir para la direccion ip de la maquina
> > (aunque no recuerdo la funcion que regresa la ip de la maquina
> > cliente)
> >
> > CREATE TABLE sanguijuelas (
> > usuario tipo_dato not null,
> > fecha timestamp not null
> > );
> >
> > CREATE RULE no_a_las_sanguijuelas AS ON UPDATE TO tabla
> > WHERE NEW.usuario <> OLD.usuario
> > DO INSTEAD
> > INSERT INTO sanguijuelas VALUES (NEW.usuario, current_timestamp);
> >
> >
> > --
> > Atentamente,
> > Jaime Casanova
> > (DBA: DataBase Aniquilator ;)
> >
>
>

--
Saludos,
Horacio Miranda Aguilera.
RedHat Certified Engineer