SEO

On 4 Jan 2006 07:36:21 -0800, carsten@uniqsys.com <carsten@uniqsys.com> wrote:
> If this is standard engine, you have to make sure that the user that's
> trying to connect has read, write, and execute permissions on the
> <dbname>.dbs directory. This can probably be achieved by adding the
> user to the group that owns the dbs directory.

No, No, No, No, No, NO, **NO** !!!!

Do not throw away all your security!

The dbname.dbs directory should have precisely 770 permission, owned
by the database owner, and belonging to group informix. Anything else
is a disaster. Similarly, all the files (.dat and .idx files) in the
database directory will belong to the user who created the table and
belong to group informix and will have 660 permission. Any relaxation
(or tightening) of these permissions breaks things.

Laxer permissions means that anyone can read the files - or write over
the files, thereby destroying the data. Indeed, setting the database
directory to 777 means that anybody, but anybody, can eliminate files
from your database (not necessarily dropping the tables; just removing
the files, or adding new ones).

Note that sqlexec should be a SUID root, SGID informix program. If it
has incorrect permissions (is missing the SGID permissions in
particular), then you run into problems, and the 'obvious' way to fix
them is by wrecking the permissions on the database directory and the
files in the database directory. However, 'obvious' is not the same
as 'correct' in this case. The correct fix is to ensure that
$INFORMIXDIR/lib/sqlexec has the correct permissions - 6511 (or, more
likely, 6755 or 6775, though no-one really needs write access and you
don't need read access on an executable to execute it - scripts, yes;
executables, no). You might also need to check that the mkdbsdir
program has the correct permissions (SUID root, SGID informix) too.

So, just to make it clear:

DO NOT SET THE PERMISSIONS ON dbase.dbs DIRECTORY TO 777.

Leave them as 770 and ensure that the group is group informix.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

Partial misfire on my part...

Jonathan Leffler wrote:
> On 4 Jan 2006 07:36:21 -0800, carsten@uniqsys.com <carsten@uniqsys.com> wrote:
>> If this is standard engine, you have to make sure that the user
>> that's trying to connect has read, write, and execute permissions
>> on the <dbname>.dbs directory. This can probably be achieved by
>> adding the user to the group that owns the dbs directory.
>
> No, No, No, No, No, NO, **NO** !!!!
>
> Do not throw away all your security!

This much is 100% valid. However, as Carsten pointed out to me offline,
what follows doesn't address what he said, precisely. More, it
addresses Maca's problems listed later - as if they were what Carsten
had said.

Having said that, what Carsten said could, I think legitimately, be
interpreted as saying "add the user to group informix", since in a
correctly installed SE installation, all database directories belong to
group informix.

This is also a complete No-No. Even within the context of an
installation that only uses SE, there is no (as in zero) call to put
anyone at all except user informix into group informix, and frankly
(with only SE on the system), you really shouldn't need to login as user
informix either. Software installs would be done by root.

Users added to group informix can corrupt any file in any database on
the system - either accidentally or on purpose. This is bad - so don't
put anyone except user informix into group informix.

If there are *any* IDS installations (or OnLine, or XPS, or ...) on the
machine, there is another whole set of reasons for not wanting anyone
except user informix in group informix. Namely, all the devices used by
IDS should be owned by user informix and belong to group informix and
have 660 permissions. Anybody who is in group informix can, therefore,
(a) read and (b) write any chunk - and effectively can destroy any IDS
instance.

So - do not put anybody except user informix into group informix.

Period.

> The dbname.dbs directory should have precisely 770 permission, owned
> by the database owner, and belonging to group informix. Anything else
> is a disaster. Similarly, all the files (.dat and .idx files) in the
> database directory will belong to the user who created the table and
> belong to group informix and will have 660 permission. Any relaxation
> (or tightening) of these permissions breaks things.
>
> Laxer permissions means that anyone can read the files - or write over
> the files, thereby destroying the data. Indeed, setting the database
> directory to 777 means that anybody, but anybody, can eliminate files
> from your database (not necessarily dropping the tables; just removing
> the files, or adding new ones).
>
> Note that sqlexec should be a SUID root, SGID informix program. If it
> has incorrect permissions (is missing the SGID permissions in
> particular), then you run into problems, and the 'obvious' way to fix
> them is by wrecking the permissions on the database directory and the
> files in the database directory. However, 'obvious' is not the same
> as 'correct' in this case. The correct fix is to ensure that
> $INFORMIXDIR/lib/sqlexec has the correct permissions - 6511 (or, more
> likely, 6755 or 6775, though no-one really needs write access and you
> don't need read access on an executable to execute it - scripts, yes;
> executables, no). You might also need to check that the mkdbsdir
> program has the correct permissions (SUID root, SGID informix) too.
>
> So, just to make it clear:
>
> DO NOT SET THE PERMISSIONS ON dbase.dbs DIRECTORY TO 777.
>
> Leave them as 770 and ensure that the group is group informix.

This commentary is accurate - it just isn't addressing what Carsten said.

Sorry, Carsten, for mis-speaking.



Maca <macanede@hotmail.com> wrote:
> first it was chmod 777 and I
> I tried with chmod:
> chmod 660 informix ,
> and I get a new error:
> choix fglgo : execute permission denied.
>
> what are the rules permission by informix.

Now I should address this message from Maca, which I think threw me off
guard in my haste this morning. According to Thunderbird, this message
from Maca was a response to Carsten's message, even though it gave no
context whatsoever.

Question to Maca - please respond with a new subject line:

What was 'chmod 777'? The database directory, or a program? Which
program? What was 'chmod 660 informix' supposed to do? There hasn't
been a program called 'informix' since Informix 3.30 was released in
about 1985-86. What is the 'choix fglgo' bit supposed to mean?

What platform are you using (operating system, version)?
Which Informix DBMS are you using (version - to the 7.25.UC1 level of
detail)? Which version of I4GL-RDS are you using?
Do you know how to set permissions on Unix machines? Do you know what
those permissions mean?
Have you altered the permissions under $INFORMIXDIR since you installed
the software?

The permissions on fglgo should be 511, or 755 (I prefer tight
permissions; the default would be either 755 or 775, with owner and
group informix). The permissions on $INFORMIXDIR/lib/sqlexec should be
4511 (4755, 4775) with owner root and group informix. The permissions
on dbase.dbs should be 770 (owner anyone trustworthy - normally the
person who creates the database - and group informix).

You can see the official permissions for the installed files by looking
in $INFORMIXDIR/etc/*files (one file list per product).

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

If $INFORMIXDIR/lib/sqlexec does not have the correct permissions, I'd
suggest the correct fix is to run the installation script again

I usually find the way the INFORMIXDIR/lib/sqlexec has the wrong
permissions is that someone has copied the files from one machine to
another via tar or simialr.

If INFORMIXDIR/lib/sqlexec is incorrect then no doubt a number of
others will be incorrect too.