Bem, primeiro observo que ** NÂO É ** um procedimento recomendado, não é uma
best practice, vc deixar usuários sairem criando ao bel-prazer (e provavelmente
SEM documentar nadica) outros usuários (e PRINCIPALMENTE se esses outros
usuários vão ter privilégio para criar objetos, E em qualquer tablespace que é
o que a role de RESOURCE dá) : eu DUVIDO que esses usuários vão seguir as
recomendações, vão criar esses objetos/outros usuários da forma correta, duvido
que vão documentar.... Isso para mim cheira ** total ** a uma banco bagunçado,
que depois um coitado de um DBA que vai ter que se virar para
corrigir/documentar..... urgh...
Agora, respondendo : as roles de CONNECT e RESOURCE por default não
possuem/implicam no privilégio de ALTER USER necessário para mudar senhas, e na
verdade NEM SEQUER incluem o privilégio de criação de outros usuários, veja no
meu banco default/padrão :
system@o10gr2:SQL>create user U_TESTE identified by u_teste;
Usußrio criado.
system@o10gr2:SQL>grant connect, resource to U_TESTE with admin option;
ConcessÒo bem-sucedida.
system@o10gr2:SQL>@h:\dba_scripts\privs_by_user
Enter Username : u_teste
Roles granted to user
GRANTED_ROLE ADM DEF
------------------------- --- ---
CONNECT YES YES
RESOURCE YES YES
Table Privileges granted to a user through roles
nÒo hß linhas selecionadas
System Privileges assigned to a user through roles
GRANTED_ROLE PRIVILEGE
------------------------- ---------------------------------
CONNECT CREATE SESSION
RESOURCE CREATE CLUSTER
RESOURCE CREATE INDEXTYPE
RESOURCE CREATE OPERATOR
RESOURCE CREATE PROCEDURE
RESOURCE CREATE SEQUENCE
RESOURCE CREATE TABLE
RESOURCE CREATE TRIGGER
RESOURCE CREATE TYPE
9 linhas selecionadas.
Table privileges assigned directly to a user
nÒo hß linhas selecionadas
System privileges assigned directly to a user
PRIVILEGE ADM
--------------------------------- ---
UNLIMITED TABLESPACE YES
system@o10gr2:SQL>connect u_teste/u_teste
Conectado.
u_teste@o10gr2:SQL>create user lalau identified by lalau;
create user lalau identified by lalau
*
ERRO na linha 1:
ORA-01031: privilÚgios insuficientes
==> então para mim tá ** CLARO ** que : OU alguém deu privilégios extras pras
roles de connect/resource, OU alguém deu privilégios de create/alter
user/sysdba/whatever para o PUBLIC, OU vc usou alguma coisa a mais, OU vc tem
trigger de DDL e quejandos aí entrando em ação e dando privs a mais, okdoc ????
Então, como falamos nas msgs anterior, VERIFIQUE quais privilégios estão
adicionados nessas roles, E verifique quais privilégios estão PUBLIC nesse
database aí, E confirme se há ou não triggers de DDl e quetais eventualmente
disparando...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Wiliam Balan <wiliambalan@...> escreveu
>
> Ops,
> o comando que usei na verdade foi:
> grant CONNECT, resource TO Usuario identified BY senha
> with admin option;
>
> o problema é que preciso que os meus usuários, possam criar outros
> usuários, por isso dei a opção deles repassarem os privilégios da roles,
> para que quando criarem um usuario, possam repassar as roles para eles. Mas
> nao gostaria que eles alterassem a senha de outros usuarios.
>
> Wiliam
>
>
>
>
>
> Em 8 de maio de 2013 12:26, Wiliam Balan <wiliambalan@...> escreveu:
>
> > Pessoal
> > fico grato pelas dicas. Eu criei os usuarios com a conta SYS com o comando
> > abaixo e atribui as Roles connect e resource somente. Será que foi por
> > causa dessas Roles? Nao dei mais nenhum privilegio.
> >
> > create user usuario identified by senha;
> >
> > GRANT CONNECT TO USUARIO
> >
> > GRANT RESOURCE TO USUARIO
> >
> >
> > Wiliam
> >
> >
> > Em 8 de maio de 2013 11:29, J. Laurindo Chiappa <jlchiappa@...>escreveu:
> >
> > **
> >>
> >>
> >> Caracoles, isso sim é que é um exemplo de alguém sem conhecimento, sem
> >> noção, sem bom-senso... Assustador...
> >> Bem, Bruno, se vc achar que há a chance desse seu database estar com um
> >> Rombo desse tipo de segurança/administração, vc (entre outros meios) para
> >> verificar se a questão é acesso público, pode executar o script que eu
> >> passei na minha msg anterior informando PUBLIC como o usuário/schema ....
> >>
> >> []s
> >>
> >> Chiappa
> >>
> >> --- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani <rodrigo@>
> >> escreveu
> >>
> >> >
> >> > Bruno,
> >> >
> >> > Eu já vi em alguns casos, alguém sem conhecimento da causa fazer o
> >> seguinte:
> >> >
> >> > grant dba to public;
> >> >
> >> >
> >> > Obs.: Isso significa que qualquer usuário que se conectar na base já é
> >> DBA. Verifique se não foi concecido privilégio de "Alter user" ou uma role
> >> que contenha tal privilégio em seu banco de dados para o usuário PUBLIC (ou
> >> seja todos).
> >> >
> >> > Atenciosamente,
> >> >
> >> > Rodrigo Mufalani
> >> > rodrigo@
> >> > www.mufalani.com.br
> >>
> >> >
> >> > On 08/05/2013, at 11:00, Bruno Sales <brunosales85@> wrote:
> >> >
> >> > > Acredito que isso só é possível se o usuario tiver privilegio de dba.
> >> > >
> >> > > Enviado via iPhone
> >> > >
> >> > > Em 08/05/2013, às 04:56, Wiliam Balan <wiliambalan@> escreveu:
> >>
> >> > >
> >> > > > Pessoal
> >> > > >
> >> > > > Sou usuário SYS do Banco e criei alguns usuários.
> >> > > > Verifiquei que pelo Oracle Sql Developer, qualquer usuário consegue
> >> alterar
> >> > > > a senha dele mesmo e de outros usuários. Tem uma opção no menu
> >> esquerdo
> >> > > > chamada "OUTROS USUARIOS" onde é possivel ver todos os usuarios do
> >> SGBD, e
> >> > > > dai voce seleciona algum e consegue por uma nova senha para ele.
> >> > > >
> >> > > > Entrei como um usuário normal e consegui alterar a senha até do SYS
> >> do BD.
> >> > > > Alguem saberia alguma forma de impedir isso?
> >> > > >
> >> > > > Wiliam
> >> > > >
> >> > > > [As partes desta mensagem que não continham texto foram removidas]
> >> > > >
> >> > > >
> >> > >
> >> > > [As partes desta mensagem que não continham texto foram removidas]
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> > [As partes desta mensagem que não continham texto foram removidas]
> >> >
> >>
> >>
> >>
> >
> >
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
