RE: [Maybe spam] Re: Relation of OS user to Informix database
- From: "Colin Dawson" <cjd_1955@xxxxxxxxxxx>
- Date: Thu, 25 Aug 2005 11:05:47 +0000
You can only revoke a privilege that exists explicitly and you are the
GRANTOR, if a user's rights are part of "public" then you cannot prevent the
access unless you revoke connection privileges from public
Regards
Colin
There are 10 types of people in the world, those that understand binary and
those that don't
>From: "Gosney Simon" <GosneyS@xxxxxxxxx>
>To: "Jonathan Leffler" <jleffler@xxxxxxxxxxxxx>, <informix-list@xxxxxxxx>
>Subject: RE: [Maybe spam] Re: Relation of OS user to Informix database
>user
>Date: Thu, 25 Aug 2005 08:48:31 +0100
>
>Jonathan... am I correct in thinking that you can't revoke rights from a
>user who has those rights because they're a member of public?
>
>Ie, if they don't have the rights assigned with an explicit GRANT
>statement, then you can't revoke their rights without revoking public's
>rights and then granting permissions to all other users individually?
>
>Cheers
>
>Simon
>
>-----Original Message-----
>From: owner-informix-list@xxxxxxxx [mailto:owner-informix-list@xxxxxxxx]
>On Behalf Of Jonathan Leffler
>Sent: 25 August 2005 05:24
>To: informix-list@xxxxxxxx
>Subject: [Maybe spam] Re: Relation of OS user to Informix database user
>
>anupam.mukherjee@xxxxxxxxx wrote:
> > I had just installed Informix Advanced Server version 10.0 for
> > Windows and was checking out the security features. I created two
> > operating system users, say A and B, gave both GRANT CONNECT and GRANT
> > RESOURCE permissions from the informix DBA user.
>
>First suggestion - don't make user 'informix' the DBA; the user already
>has an incredible amount of power (it's God w.r.t IDS). However, this
>wasn't a factor in your observations.
>
>When you created the database, was a MODE ANSI database, or a logged or
>an unlogged database. I am 95% sure it wasn't MODE ANSI...
>
> > Now, I could access
> > the entire database, including both A and B's tables by logging in as
> > either of the users.
>
>Yes. By default, in a non-ANSI database, public is given access
>permission on all tables automatically, unless you have NODEFDAC set
>correctly in the environment when the tables are created. So,
>regardless of which user (A, B, or any other user C), what you saw is
>expected behaviour. In a MODE ANSI database, no public access is given
>by default - one of the reasons I'm fairly sure you're not using such a
>database.
>
> > I tried connecting as A from dbaccess and doing a
> > REVOKE SELECT ON TABLE T FROM B. This gave an error saying no record
>in
> > ISAM and Unable to revoke permissions.
>
>Only DBAs can revoke permissions on behalf of other users. Since A is
>only resource-level user, A can only revoke permission that they've
>granted. The permission should not have been removed.
>
> > It however allowed me to do a
> > GRANT SELECT ON TABLE T TO B.
>
>Possibly - but did it actually add anything to the systabauth table? If
>
>you read the GRANT manual pages carefully, there appears to be a
>loophole such that a GRANT statement might execute 'OK' without granting
>
>the permissions.
>
> > This did not change a thing since B could
> > already access A's tables. So I did a REVOKE SELECT ON TABLE T FROM B.
>
>Since A doesn't own the table, and A is not a DBA (just resource), this
>should not achieve anything.
>
> > Next, I actually logged out and logged back in as B and still,
> > inexplicably enough, I was able to see A's tables easily enough.
>
>Since the table owner didn't do the revoking, and the DBA didn't do the
>revoking, nothing was revoked.
>
> > Any
> > explanations would be most welcome as I have been struggling to get
> > this working for sometime now.
>
>You can't revoke permissions you don't have permission to revoke.
>
> > Also any pointers to the relation of Informix's users to the
> > operating system level users would be welcome.
>
>There's a one-to-one correspondence between Informix users and O/S
>users.
>
>--
>Jonathan Leffler #include <disclaimer.h>
>Email: jleffler@xxxxxxxxxxxxx, jleffler@xxxxxxxxxx
>Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
>
>**********************************************************************
>The information in this e-mail and any attachment is confidential.
>It is intended only for the named recipient(s). If you are not a
>named recipient please notify the sender immediately and do not
>disclose the contents to another person or take copies. Although
>Axxia Systems has taken every reasonable precaution to ensure
>that any attachment to this e-mail has been checked for viruses,
>it is strongly recommended that you carry out your own virus
>check before opening any attachment, as we cannot accept
>liability for any damage sustained as a result of software virus
>infection. Axxia Systems reserves the right and senders of
>messages shall be taken to consent to the monitoring and
>recording of e-mails addressed to axxia.com.
>**********************************************************************
>sending to informix-list
sending to informix-list
.
- Prev by Date: RE: Fatal error in shared memory during system reboot
- Next by Date: Re: Relation of OS user to Informix database user
- Previous by thread: Re: Relation of OS user to Informix database
- Next by thread: Q: BTscanner - range scan savings
- Index(es):
Relevant Pages
|
