create temp table: -261 Cannot create file for table - Not owner

create temp table: -261 Cannot create file for table - Not owner

Post by Ian Wilso » Thu, 03 Apr 2003 23:45:53



After working happily for many years, part of an application started
failing with the following messages:
   Program stopped at "temp_sth.4gl", line number 19.
   SQL statement error number -261.
   Cannot create file for table (dirwatch.temp_sth).
   SYSTEM error number -1.
   Not owner

The relevant part of temp_sth.4gl is
   CREATE TEMP TABLE temp_asset
   (
   sth_asset_ref  CHAR(20)
   )

Software is I4GL 4.20 RDS and SE 5.10 on SCO OSR 505

The /tmp filesystem is not full up and setting DBTEMP doesn't help.
permissions on /tmp are normal. The code works OK on another OSR 505 system.

Permanent tables can be created and dropped OK

Does anyone have any ideas what might cause this problem?

 
 
 

create temp table: -261 Cannot create file for table - Not owner

Post by Art S. Kage » Fri, 04 Apr 2003 03:34:52



> After working happily for many years, part of an application started
> failing with the following messages:
>    Program stopped at "temp_sth.4gl", line number 19. SQL statement
>    error number -261.
>    Cannot create file for table (dirwatch.temp_sth). SYSTEM error number
>    -1.
>    Not owner

Errno = 1 is 'Not owner' as the 4GL diagnostic indicated.  Perhaps the
ownership of the database.dbs directory was accidentally changed.

Art S.Kagel

Quote:> The relevant part of temp_sth.4gl is
>    CREATE TEMP TABLE temp_asset
>    (
>    sth_asset_ref  CHAR(20)
>    )

> Software is I4GL 4.20 RDS and SE 5.10 on SCO OSR 505

> The /tmp filesystem is not full up and setting DBTEMP doesn't help.
> permissions on /tmp are normal. The code works OK on another OSR 505
> system.

> Permanent tables can be created and dropped OK

> Does anyone have any ideas what might cause this problem?


 
 
 

create temp table: -261 Cannot create file for table - Not owner

Post by Ian Wilso » Fri, 04 Apr 2003 23:20:50




>>After working happily for many years, part of an application started
>>failing with the following messages:
>>   Program stopped at "temp_sth.4gl", line number 19. SQL statement
>>   error number -261.
>>   Cannot create file for table (dirwatch.temp_sth). SYSTEM error number
>>   -1.
>>   Not owner

> Errno = 1 is 'Not owner' as the 4GL diagnostic indicated.  Perhaps the
> ownership of the database.dbs directory was accidentally changed.

The permissions look like:
drwxrwx--- dbuser dbgroup   dbname.dbs

When I log on as dbuser (primary group dbgroup) and run the app that
does "create temp" I get the error message. programs that create and
drop permanent tables work fine.

I found that $INFORMIXDIR/bin/changrp was owned by "informix", chowning
this to "root" makes the problem go away:
-rwsr-sr-x   1 root   informix   /u/rds420/bin/changrp

But could the real problem be with ownership and permissions for
systables.dat and systables.idx?

Quote:>>The relevant part of temp_sth.4gl is
>>   CREATE TEMP TABLE temp_asset
>>   (
>>   sth_asset_ref  CHAR(20)
>>   )

>>Software is I4GL 4.20 RDS and SE 5.10 on SCO OSR 505

>>The /tmp filesystem is not full up and setting DBTEMP doesn't help.
>>permissions on /tmp are normal. The code works OK on another OSR 505
>>system.

>>Permanent tables can be created and dropped OK

>>Does anyone have any ideas what might cause this problem?

--
Ian Wilson
 
 
 

create temp table: -261 Cannot create file for table - Not owner

Post by Obnoxio The Clow » Sat, 05 Apr 2003 05:26:23





>>>After working happily for many years, part of an application started
>>>failing with the following messages:
>>>   Program stopped at "temp_sth.4gl", line number 19. SQL statement
>>>   error number -261.
>>>   Cannot create file for table (dirwatch.temp_sth). SYSTEM error number
>>>   -1.
>>>   Not owner

>> Errno = 1 is 'Not owner' as the 4GL diagnostic indicated.  Perhaps the
>> ownership of the database.dbs directory was accidentally changed.

> The permissions look like:
> drwxrwx--- dbuser dbgroup   dbname.dbs

> When I log on as dbuser (primary group dbgroup) and run the app that
> does "create temp" I get the error message. programs that create and
> drop permanent tables work fine.

> I found that $INFORMIXDIR/bin/changrp was owned by "informix", chowning
> this to "root" makes the problem go away:
> -rwsr-sr-x   1 root   informix   /u/rds420/bin/changrp

My next thought was that some of the binaries might not have the right
permissions...
 
 
 

create temp table: -261 Cannot create file for table - Not owner

Post by Jonathan Leffle » Sat, 05 Apr 2003 13:36:30





>>> After working happily for many years, part of an application started
>>> failing with the following messages:
>>>   Program stopped at "temp_sth.4gl", line number 19. SQL statement
>>>   error number -261.
>>>   Cannot create file for table (dirwatch.temp_sth). SYSTEM error number
>>>   -1.
>>>   Not owner

>> Errno = 1 is 'Not owner' as the 4GL diagnostic indicated.  Perhaps the
>> ownership of the database.dbs directory was accidentally changed.

> The permissions look like:
> drwxrwx--- dbuser dbgroup   dbname.dbs

That's dubious; the group should be informix.  Then dbuser would own
the database, but the SGID informix program sqlexec would be able to
access the files in the database directory - and create them, etc.

Quote:> When I log on as dbuser (primary group dbgroup) and run the app that
> does "create temp" I get the error message. programs that create and
> drop permanent tables work fine.

Where are the temp tables being created?  Where does $DBTEMP point to?
  What are the permissions on /tmp and /usr/tmp?

Quote:> I found that $INFORMIXDIR/bin/changrp was owned by "informix", chowning
> this to "root" makes the problem go away:
> -rwsr-sr-x   1 root   informix   /u/rds420/bin/changrp

That would certainly help.  $INFORMIXDIR/etc/sefiles lists all the
files in the distribution and the owner, group and permissions that
should be set on the files.  There's a toolkit in the IIUG Software
Archive, utils_jl, which has tools ixchkperm and ixsetperm to sort out
permissions problems.  The permissions on $INFORMIXDIR/lib/sqlexec are
also extremely important (owner root, group informix, 6755 - though
6711 or 6511 or 6111 would also be OK; the 6 indicates SUID and SGID).

Quote:> But could the real problem be with ownership and permissions for
> systables.dat and systables.idx?

In part - but not for temporary tables since they are not detailed in
the system catalog.  The owner of the system catalog should be either
informix or the database owner, the group should be informix, and the
permissions should be 660.

Quote:>>> The relevant part of temp_sth.4gl is
>>>   CREATE TEMP TABLE temp_asset
>>>   (
>>>   sth_asset_ref  CHAR(20)
>>>   )

>>> Software is I4GL 4.20 RDS and SE 5.10 on SCO OSR 505

>>> The /tmp filesystem is not full up and setting DBTEMP doesn't help.
>>> permissions on /tmp are normal. The code works OK on another OSR 505
>>> system.

So what are the permissions on /tmp?  777, possibly with the sticky
bit set (1777).

Quote:>>> Permanent tables can be created and dropped OK

>>> Does anyone have any ideas what might cause this problem?

I think you've got the answer - permissions.

You might try to find out who changed the permissions on the system
and why, because they're likely to do it again, and then you'll have
to fix it again. It is usually an over-zealous sys admin removing SUID
root programs from the system who does the damage.

--
Jonathan Leffler                   #include <disclaimer.h>

Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

 
 
 

create temp table: -261 Cannot create file for table - Not owner

Post by Ian Wilso » Sat, 05 Apr 2003 19:11:28






>>>> After working happily for many years, part of an application started
>>>> failing with the following messages:
>>>>   Program stopped at "temp_sth.4gl", line number 19. SQL statement
>>>>   error number -261.
>>>>   Cannot create file for table (dirwatch.temp_sth). SYSTEM error number
>>>>   -1.
>>>>   Not owner

>>> Errno = 1 is 'Not owner' as the 4GL diagnostic indicated.  Perhaps the
>>> ownership of the database.dbs directory was accidentally changed.

>> The permissions look like:
>> drwxrwx--- dbuser dbgroup   dbname.dbs

> That's dubious; the group should be informix.  Then dbuser would own the
> database, but the SGID informix program sqlexec would be able to access
> the files in the database directory - and create them, etc.

I think I need to read some best-practice guidelines on this. Here's how
I arrived at this arrangement:

* Aim to give users the least privileges needed to do the job.
* Aim to give programs the least privileges to do the job.
* Lock down permissions until nothing works then back off until they do.
* Create a group for the app and have all users be a member of it.
   this will be how they get permissions to the app & data.
* A separate user (appowner) owns the app binaries/pcode.
* the app binaries/pcode get g=rx,o-rwx and group appgroup
* Informix runtime gets installed and left as its makers intended.
* The database directory is user appowner, group appgroup g=rwx
* The dat/idx files get owned by appowner, group appgrp g=rw
   so that users can read and write data using the app.

I guess I'll try your advice and change the group to informix.
Do the users need membership of group informix?

Quote:>> When I log on as dbuser (primary group dbgroup) and run the app that
>> does "create temp" I get the error message. programs that create and
>> drop permanent tables work fine.

> Where are the temp tables being created?  

In /tmp, I confirmed this by monitoring its contents during program
execution.

Quote:> Where does $DBTEMP point to?

It is undefined, so /tmp gets used.
Pointing $DBTEMP at a directory created for that purpose didn't help

Quote:> What are the permissions on /tmp and /usr/tmp?

1$ ls -ld /tmp /usr/tmp
drwxrwxrwt   2 sys      sys         7680 Apr  4 11:02 /tmp
drwxrwxrwt   2 sys      sys          512 Apr  4 08:47 /usr/tmp

Quote:>> I found that $INFORMIXDIR/bin/changrp was owned by "informix",
>> chowning this to "root" makes the problem go away:
>> -rwsr-sr-x   1 root   informix   /u/rds420/bin/changrp

> That would certainly help.  $INFORMIXDIR/etc/sefiles lists all the files
> in the distribution and the owner, group and permissions that should be
> set on the files.  There's a toolkit in the IIUG Software Archive,
> utils_jl, which has tools ixchkperm and ixsetperm to sort out
> permissions problems.  The permissions on $INFORMIXDIR/lib/sqlexec are
> also extremely important (owner root, group informix, 6755 - though 6711
> or 6511 or 6111 would also be OK; the 6 indicates SUID and SGID).

Thanks, good stuff, will try it out.

Quote:>> But could the real problem be with ownership and permissions for
>> systables.dat and systables.idx?

> In part - but not for temporary tables since they are not detailed in
> the system catalog.  The owner of the system catalog should be either
> informix or the database owner, the group should be informix, and the
> permissions should be 660.

OK, thanks.

- Show quoted text -

Quote:>>>> The relevant part of temp_sth.4gl is
>>>>   CREATE TEMP TABLE temp_asset
>>>>   (
>>>>   sth_asset_ref  CHAR(20)
>>>>   )

>>>> Software is I4GL 4.20 RDS and SE 5.10 on SCO OSR 505

>>>> The /tmp filesystem is not full up and setting DBTEMP doesn't help.
>>>> permissions on /tmp are normal. The code works OK on another OSR 505
>>>> system.

> So what are the permissions on /tmp?  777, possibly with the sticky bit
> set (1777).

Yes - see above

Quote:>>>> Permanent tables can be created and dropped OK

>>>> Does anyone have any ideas what might cause this problem?

> I think you've got the answer - permissions.

> You might try to find out who changed the permissions on the system
> and why, because they're likely to do it again, and then you'll have
> to fix it again. It is usually an over-zealous sys admin removing SUID
> root programs from the system who does the damage.

The customer's main IT support staff did tighten security recently. I'd
expect they'd consult us (their app supplier and supporter) before
altering the permissions on the Informix runtime. Some tactful enquiries
  may be in order!
 
 
 

create temp table: -261 Cannot create file for table - Not owner

Post by Obnoxio The Clow » Sat, 05 Apr 2003 20:26:53







>>>>> After working happily for many years, part of an application started
>>>>> failing with the following messages:
>>>>>   Program stopped at "temp_sth.4gl", line number 19. SQL statement
>>>>>   error number -261.
>>>>>   Cannot create file for table (dirwatch.temp_sth). SYSTEM error
>>>>>   number -1.
>>>>>   Not owner

>>>> Errno = 1 is 'Not owner' as the 4GL diagnostic indicated.  Perhaps the
>>>> ownership of the database.dbs directory was accidentally changed.

>>> The permissions look like:
>>> drwxrwx--- dbuser dbgroup   dbname.dbs

>> That's dubious; the group should be informix.  Then dbuser would own the
>> database, but the SGID informix program sqlexec would be able to access
>> the files in the database directory - and create them, etc.

> I think I need to read some best-practice guidelines on this. Here's how
> I arrived at this arrangement:

> * Aim to give users the least privileges needed to do the job.
> * Aim to give programs the least privileges to do the job.
> * Lock down permissions until nothing works then back off until they do.
> * Create a group for the app and have all users be a member of it.
>    this will be how they get permissions to the app & data.
> * A separate user (appowner) owns the app binaries/pcode.
> * the app binaries/pcode get g=rx,o-rwx and group appgroup
> * Informix runtime gets installed and left as its makers intended.
> * The database directory is user appowner, group appgroup g=rwx
> * The dat/idx files get owned by appowner, group appgrp g=rw
>    so that users can read and write data using the app.

* Make sure that your permissions are acceptable to the database server?

Have you considered using the approved mechanism for GRANTing and REVOKEing
permissions at the database level? I mean, that's why they are there. I'd
be a bit concerned about stuffing around with the pcode/binaries, too.

Quote:> I guess I'll try your advice and change the group to informix.
> Do the users need membership of group informix?

No. In fact, they should definitely not have such permission.

- Show quoted text -

Quote:>>> When I log on as dbuser (primary group dbgroup) and run the app that
>>> does "create temp" I get the error message. programs that create and
>>> drop permanent tables work fine.

>> Where are the temp tables being created?

> In /tmp, I confirmed this by monitoring its contents during program
> execution.

>> Where does $DBTEMP point to?

> It is undefined, so /tmp gets used.
> Pointing $DBTEMP at a directory created for that purpose didn't help

>> What are the permissions on /tmp and /usr/tmp?

> 1$ ls -ld /tmp /usr/tmp
> drwxrwxrwt   2 sys      sys         7680 Apr  4 11:02 /tmp
> drwxrwxrwt   2 sys      sys          512 Apr  4 08:47 /usr/tmp

>>> I found that $INFORMIXDIR/bin/changrp was owned by "informix",
>>> chowning this to "root" makes the problem go away:
>>> -rwsr-sr-x   1 root   informix   /u/rds420/bin/changrp

>> That would certainly help.  $INFORMIXDIR/etc/sefiles lists all the files
>> in the distribution and the owner, group and permissions that should be
>> set on the files.  There's a toolkit in the IIUG Software Archive,
>> utils_jl, which has tools ixchkperm and ixsetperm to sort out
>> permissions problems.  The permissions on $INFORMIXDIR/lib/sqlexec are
>> also extremely important (owner root, group informix, 6755 - though 6711
>> or 6511 or 6111 would also be OK; the 6 indicates SUID and SGID).

> Thanks, good stuff, will try it out.

>>> But could the real problem be with ownership and permissions for
>>> systables.dat and systables.idx?

>> In part - but not for temporary tables since they are not detailed in
>> the system catalog.  The owner of the system catalog should be either
>> informix or the database owner, the group should be informix, and the
>> permissions should be 660.

> OK, thanks.

>>>>> The relevant part of temp_sth.4gl is
>>>>>   CREATE TEMP TABLE temp_asset
>>>>>   (
>>>>>   sth_asset_ref  CHAR(20)
>>>>>   )

>>>>> Software is I4GL 4.20 RDS and SE 5.10 on SCO OSR 505

>>>>> The /tmp filesystem is not full up and setting DBTEMP doesn't help.
>>>>> permissions on /tmp are normal. The code works OK on another OSR 505
>>>>> system.

>> So what are the permissions on /tmp?  777, possibly with the sticky bit
>> set (1777).

> Yes - see above

>>>>> Permanent tables can be created and dropped OK

>>>>> Does anyone have any ideas what might cause this problem?

>> I think you've got the answer - permissions.

>> You might try to find out who changed the permissions on the system
>> and why, because they're likely to do it again, and then you'll have
>> to fix it again. It is usually an over-zealous sys admin removing SUID
>> root programs from the system who does the damage.

> The customer's main IT support staff did tighten security recently. I'd
> expect they'd consult us (their app supplier and supporter) before
> altering the permissions on the Informix runtime. Some tactful enquiries
>   may be in order!

 
 
 

create temp table: -261 Cannot create file for table - Not owner

Post by Ian Wilso » Sat, 05 Apr 2003 22:09:22








>>>>>>After working happily for many years, part of an application started
>>>>>>failing with the following messages:
>>>>>>  Program stopped at "temp_sth.4gl", line number 19. SQL statement
>>>>>>  error number -261.
>>>>>>  Cannot create file for table (dirwatch.temp_sth). SYSTEM error
>>>>>>  number -1.
>>>>>>  Not owner

>>>>>Errno = 1 is 'Not owner' as the 4GL diagnostic indicated.  Perhaps the
>>>>>ownership of the database.dbs directory was accidentally changed.

>>>>The permissions look like:
>>>>drwxrwx--- dbuser dbgroup   dbname.dbs

>>>That's dubious; the group should be informix.  Then dbuser would own the
>>>database, but the SGID informix program sqlexec would be able to access
>>>the files in the database directory - and create them, etc.

>>I think I need to read some best-practice guidelines on this. Here's how
>>I arrived at this arrangement:

>>* Aim to give users the least privileges needed to do the job.
>>* Aim to give programs the least privileges to do the job.
>>* Lock down permissions until nothing works then back off until they do.
>>* Create a group for the app and have all users be a member of it.
>>   this will be how they get permissions to the app & data.
>>* A separate user (appowner) owns the app binaries/pcode.
>>* the app binaries/pcode get g=rx,o-rwx and group appgroup
>>* Informix runtime gets installed and left as its makers intended.
>>* The database directory is user appowner, group appgroup g=rwx
>>* The dat/idx files get owned by appowner, group appgrp g=rw
>>   so that users can read and write data using the app.

> * Make sure that your permissions are acceptable to the database server?

Who's in charge here? ;-)
This makes sense with your subsequent point. Users can only access the
data files through the SUID/SGID sqlexec. So access controls get
enforced by the DB engine.

Quote:

> Have you considered using the approved mechanism for GRANTing and REVOKEing
> permissions at the database level?

<fx: stares at feet>

Quote:> I mean, that's why they are there.

Well OK, I just need to make sure that Joe Newbie can't accidentally rm
the tables frum under the DB engine's elbows.

Quote:> I'd be a bit concerned about stuffing around with the pcode/binaries, too.

Each developer seems to have differing groups and umasks that affect the
ownership, group and permissions of the pcode/binaries they create. I
just like to make things consistent.

Quote:

>>I guess I'll try your advice and change the group to informix.
>>Do the users need membership of group informix?

> No. In fact, they should definitely not have such permission.

Sounds good to me.

- Show quoted text -

Quote:>>>>When I log on as dbuser (primary group dbgroup) and run the app that
>>>>does "create temp" I get the error message. programs that create and
>>>>drop permanent tables work fine.

>>>Where are the temp tables being created?

>>In /tmp, I confirmed this by monitoring its contents during program
>>execution.

>>>Where does $DBTEMP point to?

>>It is undefined, so /tmp gets used.
>>Pointing $DBTEMP at a directory created for that purpose didn't help

>>>What are the permissions on /tmp and /usr/tmp?

>>1$ ls -ld /tmp /usr/tmp
>>drwxrwxrwt   2 sys      sys         7680 Apr  4 11:02 /tmp
>>drwxrwxrwt   2 sys      sys          512 Apr  4 08:47 /usr/tmp

>>>>I found that $INFORMIXDIR/bin/changrp was owned by "informix",
>>>>chowning this to "root" makes the problem go away:
>>>>-rwsr-sr-x   1 root   informix   /u/rds420/bin/changrp

>>>That would certainly help.  $INFORMIXDIR/etc/sefiles lists all the files
>>>in the distribution and the owner, group and permissions that should be
>>>set on the files.  There's a toolkit in the IIUG Software Archive,
>>>utils_jl, which has tools ixchkperm and ixsetperm to sort out
>>>permissions problems.  The permissions on $INFORMIXDIR/lib/sqlexec are
>>>also extremely important (owner root, group informix, 6755 - though 6711
>>>or 6511 or 6111 would also be OK; the 6 indicates SUID and SGID).

>>Thanks, good stuff, will try it out.

>>>>But could the real problem be with ownership and permissions for
>>>>systables.dat and systables.idx?

>>>In part - but not for temporary tables since they are not detailed in
>>>the system catalog.  The owner of the system catalog should be either
>>>informix or the database owner, the group should be informix, and the
>>>permissions should be 660.

>>OK, thanks.

>>>>>>The relevant part of temp_sth.4gl is
>>>>>>  CREATE TEMP TABLE temp_asset
>>>>>>  (
>>>>>>  sth_asset_ref  CHAR(20)
>>>>>>  )

>>>>>>Software is I4GL 4.20 RDS and SE 5.10 on SCO OSR 505

>>>>>>The /tmp filesystem is not full up and setting DBTEMP doesn't help.
>>>>>>permissions on /tmp are normal. The code works OK on another OSR 505
>>>>>>system.

>>>So what are the permissions on /tmp?  777, possibly with the sticky bit
>>>set (1777).

>>Yes - see above

>>>>>>Permanent tables can be created and dropped OK

>>>>>>Does anyone have any ideas what might cause this problem?

>>>I think you've got the answer - permissions.

>>>You might try to find out who changed the permissions on the system
>>>and why, because they're likely to do it again, and then you'll have
>>>to fix it again. It is usually an over-zealous sys admin removing SUID
>>>root programs from the system who does the damage.

>>The customer's main IT support staff did tighten security recently. I'd
>>expect they'd consult us (their app supplier and supporter) before
>>altering the permissions on the Informix runtime. Some tactful enquiries
>>  may be in order!

 
 
 

create temp table: -261 Cannot create file for table - Not owner

Post by Obnoxio The Clow » Sun, 06 Apr 2003 10:32:03



>> * Make sure that your permissions are acceptable to the database server?

> Who's in charge here? ;-)
> This makes sense with your subsequent point. Users can only access the
> data files through the SUID/SGID sqlexec. So access controls get
> enforced by the DB engine.

>> Have you considered using the approved mechanism for GRANTing and
>> REVOKEing permissions at the database level?

> <fx: stares at feet>

>> I mean, that's why they are there.

> Well OK, I just need to make sure that Joe Newbie can't accidentally rm
> the tables frum under the DB engine's elbows.

If the file permissions on the binaries and .dbs directories are set as
recommended by Informix, and you don't grant users unneccesary DBA or
RESOURCE privileges, you should be OK.

Oh, and don't hand out the root or informix password either. :o)

 
 
 

1. Temp Table - Cannot read data that has just been created

In a stored procedure, I am trying to create a table and then read it
from within that SP or from another one (nested). When I run the below
code (simplified version of my real SP), no records are returned even
though I know that there is data. The table is created and records are
inserted, I just cannot read the records from the SP or one that calls
it with an EXEC.

Any ideas? My code is listed below. (When I get this to work, I plan
to convert the code to manipulate a temp table).

Alter Procedure spWod_rptWoStatusSummary_9

As
BEGIN
CREATE TABLE tblStatusSummary (TckStaffCd_F Char(3), RecType Char(20))
INSERT INTO tblStatusSummary
SELECT TckStaffCd_F, RecType
END

BEGIN
Select * from tblStatusSummary
end

2. Backing up to tape

3. Simple question: cannot create, drop, recreate temp table

4. Error while Posting data

5. Cannot Create temp table within Store procedure??

6. CHECK constraints on SQL7 vs SQL 2000

7. Cannot create a cursor to access a temp table

8. Sequences in Oracle

9. Cannot create temp tables

10. How to create a table and not to be the dbo Owner

11. Difference btwn CREATE VIEW and CREATE TABLE TEMP

12. Create View vs. Create Table Temp

13. Temp table not being created