NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/database/sybase/757

Internet Message Format | 1993-01-28 | 1.7 KB

Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!usc!howland.reston.ans.net!spool.mu.edu!hri.com!noc.near.net!transfer.stratus.com!dwetzel.mis.stratus.com!user
From: [e-mail] (David Wetzel)
Newsgroups: comp.databases.sybase
Subject: Re: Problem with 4.0.1 user Permissions, SGI
Message-ID: <[e-mail]>
Date: 27 Jan 93 16:50:23 GMT
References: <[e-mail]>
Followup-To: comp.databases.sybase
Organization: Stratus Computer
Lines: 44
NNTP-Posting-Host: dwetzel.mis.stratus.com

In article <[e-mail]>,
[e-mail] (Phil McMillan) wrote:

> when I type (as "sa" user)
>
>     revoke all from user
>
> it doesnt change the permissions, ie the "user" can still insert.
>
> However, when I type (as "sa")
>
>     revoke all on table from user
>
> The changes take effect. ie can no longer insert.

This is pretty easy.  The grant/revoke command not only works for
permissions on objects it also manages permissions on commands (like create
table, create default, etc).  So if the server sees "revoke all from user"
with no object refered to it will assume that you're talking about revoking
commands.

The way to test it is this:

   grant create proc to user
   go
   grant select on table to user
   go
   revoke all from user
   go
   sp_helprotect user
   go

This will show the user still has access to select from the table, but no
longer has create proc access.  Next do:

   revoke all on table to user
   go
   sp_helprotect user
   go

Now the user should have also lost access to select from table.

Thanks,
[e-mail]