-648 error opening DEBUG file
On Informix 7.30 on HP-UX 10.20, a stored procedure failed at SET DEBUG FILE with error -648 plus "1: Not owner" for any non-root user, even though the target /tmp was world-writable and the file didn't exist (pre-creating it didn't help). Jonathan Leffler traced it to the oninit binary's ownership/permissions: it was informix:informix (-rwsr-sr--) instead of the expected root:informix with setuid (6754/6755), so the server couldn't create/chown the trace file. Correcting oninit's ownership was advised as the root cause; a side note was that /tmp should carry the sticky bit (1777). The poster never confirmed the fix in the thread.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
This will be a long post, as I am trying to get all of the relevant
information in the first posting.
I have a problem in an old environment. This is Informix 7.30.UC7, running on
HP-UX 10.20. Yes, I know, neither of these are supported by their respective
vendors anymore, but this is the environment in which I need this to run.
OK, I have a stored procedure that does a "set debug file ..." statement, then
has various trace statements. The debug file is being sent to /tmp/test.trace.
There is no such file in the /tmp directory, and /tmp has 777 permissions.
The problem is, if anyone other than root tries to execute this procedure, we
get the -648 error, followed by a second message "1: Not owner". As I said,
the file doesn't exist, so it can't be complaining about file ownership. It
also has nothing to do with ownership of the procedure, as the error occurs
even when running the proc as the same user that created it.
The test procedure that I've created is:
create procedure test_proc()
define p_count integer;
set debug file to "/tmp/test.trace";
trace "Starting test_proc()";
trace "Selecting count(*) from mydb:employee";
select count(*)
into p_count
from mydb:employee;
trace "mydb:employee has " || p_count || " rows.";
trace "Selecting count(*) from another_db:employee";
select count(*)
into p_count
from another_db:employee;
trace "another_db:employee has " || p_count || " rows.";
trace "Ending test_proc()";
end procedure;
The failure occurs as soon as it hits the "set debug ..." statement. I have
also tried setting the directory to be the home directory of the procedure's
owner.
One possible wrinkle is that this system was at one time converted to
"trusted" status (not an HP-UX guru, so I'm going with what others have told
me -- I'm also told that "trusted" is no longer a part of the newer HP-UX
versions). That was done because all of the other HP-UX boxes in the shop were
"trusted". Unfortunately, after the conversion, this box had problems, so they
reverted to non-trusted status. I don't know if that has any bearing on this
issue or not, but thought I should mention it.
This is now the only non-trusted server in the shop. This procedure needs to
access databases on both the trusted and this non-trusted hosts.
Unfortunately, running dbaccess on any of the trusted servers, you can not
connect to the databases on this non-trusted server, so the procedure needs to
run on this non-trusted server, unless someone can explain how to connect from
the trusted servers to the databases on this non-trusted server.
The test procedure (and the real procedure) run on the trusted servers with no
problem, but they can not connect to the databases on the non-trusted server.
If we try to connect from the trusted to the non-trusted, we get "956: Client
host or user (my_user@my_host) is not trusted by the server. Permission
denied". I have verified that the non-trusted host has an entry in
/etc/hosts.equiv that matches the trusted server which is trying to connect. I
have added an entry in my .netrc, but that changes the error to "952: User's
password is not correct for the database server. No such file or directory",
even though I have confirmed the password is correct.
Does your debug file live in a place accessible to other users?
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of MARK
COLLINS
Sent: Wednesday, January 26, 2011 10:37 AM
To: ids@iiug.org
Subject: -648 error opening DEBUG file [22570]
This will be a long post, as I am trying to get all of the relevant
information in the first posting.
I have a problem in an old environment. This is Informix 7.30.UC7, running on
HP-UX 10.20. Yes, I know, neither of these are supported by their respective
vendors anymore, but this is the environment in which I need this to run.
OK, I have a stored procedure that does a "set debug file ..." statement, then
has various trace statements. The debug file is being sent to /tmp/test.trace.
There is no such file in the /tmp directory, and /tmp has 777 permissions.
The problem is, if anyone other than root tries to execute this procedure, we
get the -648 error, followed by a second message "1: Not owner". As I said,
the file doesn't exist, so it can't be complaining about file ownership. It
also has nothing to do with ownership of the procedure, as the error occurs
even when running the proc as the same user that created it.
The test procedure that I've created is:
create procedure test_proc()
define p_count integer;
set debug file to "/tmp/test.trace";
trace "Starting test_proc()";
trace "Selecting count(*) from mydb:employee";
select count(*)
into p_count
from mydb:employee;
trace "mydb:employee has " || p_count || " rows.";
trace "Selecting count(*) from another_db:employee";
select count(*)
into p_count
from another_db:employee;
trace "another_db:employee has " || p_count || " rows.";
trace "Ending test_proc()";
end procedure;
The failure occurs as soon as it hits the "set debug ..." statement. I have
also tried setting the directory to be the home directory of the procedure's
owner.
One possible wrinkle is that this system was at one time converted to
"trusted" status (not an HP-UX guru, so I'm going with what others have told
me -- I'm also told that "trusted" is no longer a part of the newer HP-UX
versions). That was done because all of the other HP-UX boxes in the shop were
"trusted". Unfortunately, after the conversion, this box had problems, so they
reverted to non-trusted status. I don't know if that has any bearing on this
issue or not, but thought I should mention it.
This is now the only non-trusted server in the shop. This procedure needs to
access databases on both the trusted and this non-trusted hosts.
Unfortunately, running dbaccess on any of the trusted servers, you can not
connect to the databases on this non-trusted server, so the procedure needs to
run on this non-trusted server, unless someone can explain how to connect from
the trusted servers to the databases on this non-trusted server.
The test procedure (and the real procedure) run on the trusted servers with no
problem, but they can not connect to the databases on the non-trusted server.
If we try to connect from the trusted to the non-trusted, we get "956: Client
host or user (my_user@my_host) is not trusted by the server. Permission
denied". I have verified that the non-trusted host has an entry in
/etc/hosts.equiv that matches the trusted server which is trying to connect. I
have added an entry in my .netrc, but that changes the error to "952: User's
password is not correct for the database server. No such file or directory",
even though I have confirmed the password is correct.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
On Wed, Jan 26, 2011 at 07:37, MARK COLLINS <markc@myfastmail.com> wrote:
> This will be a long post, as I am trying to get all of the relevant
> information in the first posting.
>
> I have a problem in an old environment. This is Informix 7.30.UC7, running
> on
> HP-UX 10.20. Yes, I know, neither of these are supported by their
> respective
> vendors anymore, but this is the environment in which I need this to run.
>
> OK, I have a stored procedure that does a "set debug file ..." statement,
> then
> has various trace statements. The debug file is being sent to
> /tmp/test.trace.
> There is no such file in the /tmp directory, and /tmp has 777 permissions.
>
Usually, /tmp should have 1777 permissions - the sticky bit should be set so
that someone other than the owner (or root) without write permission on the
file should not be able to delete it.
> The problem is, if anyone other than root tries to execute this procedure,
> we
> get the -648 error, followed by a second message "1: Not owner". As I said,
> the file doesn't exist, so it can't be complaining about file ownership. It
> also has nothing to do with ownership of the procedure, as the error occurs
> even when running the proc as the same user that created it.
>
Have you tried creating the file before running the procedure?
In the circumstances, 666 permission might be appropriate for the test
Have you checked the permissions on oninit itself? It should be
root:informix:6755 or root:informix:6754 - the 4 is as-shipped, the 5 is OK.
> The test procedure that I've created is:
>
> create procedure test_proc()>
> define p_count integer;
>
> set debug file to "/tmp/test.trace";
>
> trace "Starting test_proc()";
>
> trace "Selecting count(*) from mydb:employee";
>
> select count(*)>
> into p_count
>
> from mydb:employee;
>
> trace "mydb:employee has " || p_count || " rows.";
>
> trace "Selecting count(*) from another_db:employee";
>
> select count(*)>
> into p_count
>
> from another_db:employee;
>
> trace "another_db:employee has " || p_count || " rows.";
>
> trace "Ending test_proc()";
>
> end procedure;
>
> The failure occurs as soon as it hits the "set debug ..." statement. I have
> also tried setting the directory to be the home directory of the
> procedure's
> owner.
>
The 1 EPERM "Not owner" suggests that the server was not empowered to create
the file, or (more likely) not empowered to change ownership on the file -
hence my question about the permissions on 'oninit'.
> One possible wrinkle is that this system was at one time converted to
> "trusted" status (not an HP-UX guru, so I'm going with what others have
> told
> me -- I'm also told that "trusted" is no longer a part of the newer HP-UX
> versions). That was done because all of the other HP-UX boxes in the shop
> were
> "trusted". Unfortunately, after the conversion, this box had problems, so
> they
> reverted to non-trusted status. I don't know if that has any bearing on
> this
> issue or not, but thought I should mention it.
>
> This is now the only non-trusted server in the shop. This procedure needs
> to
> access databases on both the trusted and this non-trusted hosts.
> Unfortunately, running dbaccess on any of the trusted servers, you can not
> connect to the databases on this non-trusted server, so the procedure needs
> to
> run on this non-trusted server, unless someone can explain how to connect
> from
> the trusted servers to the databases on this non-trusted server.
>
If there are permissions problems, they could have been created when the
reversion from trusted to non-trusted occurred.
> The test procedure (and the real procedure) run on the trusted servers with
> no
> problem, but they can not connect to the databases on the non-trusted
> server.
> If we try to connect from the trusted to the non-trusted, we get "956:
> Client
> host or user (my_user@my_host) is not trusted by the server. Permission
> denied". I have verified that the non-trusted host has an entry in
> /etc/hosts.equiv that matches the trusted server which is trying to
> connect. I
> have added an entry in my .netrc, but that changes the error to "952:
> User's
> password is not correct for the database server. No such file or
> directory",
> even though I have confirmed the password is correct.
>
--
Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
--20cf30433ed254514d049ac1d588
Well, it doesn't exist at this time. I'm trying to create it in /tmp, and /tmp has 777 permissions, so yes, it is accessible to other users.
Please include context in your answer - this is all I got. I know roughly what the overall issue is; I've no idea which of the responses received it is a comment on. On Wed, Jan 26, 2011 at 08:23, MARK COLLINS <markc@myfastmail.com> wrote: > Well, it doesn't exist at this time. I'm trying to create it in /tmp, and > /tmp > has 777 permissions, so yes, it is accessible to other users. > Please people - think! -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." --001636c5b45f728e20049ac2593e
>>Usually, /tmp should have 1777 permissions - the sticky bit should be set
>>so that someone other than the owner (or root) without write permission
>> on the file should not be able to delete it.
There is no sticky bit set at this time. The permissions block in ls -ld /tmp
shows drwxrwxrwx. Would that prevent the procedure from creating the debug
file?
>>Have you tried creating the file before running the procedure?
>>
>>In the circumstances, 666 permission might be appropriate for the test
I didn't mention that, but yes, I did try creating the file, using 'touch'. I
don't recall if it was 666 or 777 permissions, but I still got the error.
>>Have you checked the permissions on oninit itself? It should be
>>root:informix:6755 or root:informix:6754 - the 4 is as-shipped, the 5 is
>>OK.
Hmm, that's different. I have:
-rwsr-sr-- 1 informix informix 7436702 Feb 8 1999 oninit
Can the informix:informix ownership be part of the problem?
>>The 1 EPERM "Not owner" suggests that the server was not empowered to
>>create the file, or (more likely) not empowered to change ownership on
>>the file - hence my question about the permissions on 'oninit'.
The error occurs whether the file exists or not, so I don't think it's
anything to do with changing ownership. And, since /tmp has 777 (not 1777)
permissions, it seems that anyone should be able to create the file.
>>If there are permissions problems, they could have been created when the
>>reversion from trusted to non-trusted occurred.
That was one theory proposed by the current Unix admin. Unfortunately, the
reversion happened many years ago, and the people who did it are long gone, so
there is no way of knowing how they went about the process.
Sorry. When I posted the response, I thought that the original posting would be included in my response, as happens on other forums. The question that was asked was whether the debug file existed in a place that was accessible to other users. Thus my response, that the file does not currently exist (unless I create an empty file via 'touch'), and that the procedure was trying to create the debug file in /tmp, which has permissions for everyone to do anything. Please include context in your answer - this is all I got. I know roughly what the overall issue is; I've no idea which of the responses received it is a comment on. On Wed, Jan 26, 2011 at 08:23, MARK COLLINS <markc@myfastmail.com> wrote: > Well, it doesn't exist at this time. I'm trying to create it in /tmp, and > /tmp > has 777 permissions, so yes, it is accessible to other users. > Please people - think!
>>Have you checked the permissions on oninit itself? It should be
>>root:informix:6755 or root:informix:6754 - the 4 is as-shipped, the 5 is
>>OK.
Didn't there used to be a utility or shell script or something that would
check owner/group/permissions on all of the Informix components, to validate
an install?
Yes. It should be root:informix
Art
On Jan 26, 2011 9:36 AM, "MARK COLLINS" <markc@myfastmail.com> wrote:
>>>Usually, /tmp should have 1777 permissions - the sticky bit should be set
>>>so that someone other than the owner (or root) without write permission
>>> on the file should not be able to delete it.
>
> There is no sticky bit set at this time. The permissions block in ls -ld
/tmp
> shows drwxrwxrwx. Would that prevent the procedure from creating the debug
> file?
>
>>>Have you tried creating the file before running the procedure?
>>>
>>>In the circumstances, 666 permission might be appropriate for the test
>
> I didn't mention that, but yes, I did try creating the file, using
'touch'. I
> don't recall if it was 666 or 777 permissions, but I still got the error.
>
>>>Have you checked the permissions on oninit itself? It should be
>>>root:informix:6755 or root:informix:6754 - the 4 is as-shipped, the 5 is
>>>OK.
>
> Hmm, that's different. I have:
>
> -rwsr-sr-- 1 informix informix 7436702 Feb 8 1999 oninit
>
> Can the informix:informix ownership be part of the problem?
>
>>>The 1 EPERM "Not owner" suggests that the server was not empowered to
>>>create the file, or (more likely) not empowered to change ownership on
>>>the file - hence my question about the permissions on 'oninit'.
>
> The error occurs whether the file exists or not, so I don't think it's
> anything to do with changing ownership. And, since /tmp has 777 (not 1777)
> permissions, it seems that anyone should be able to create the file.
>
>>>If there are permissions problems, they could have been created when the
>>>reversion from trusted to non-trusted occurred.
>
> That was one theory proposed by the current Unix admin. Unfortunately, the
> reversion happened many years ago, and the people who did it are long
gone, so
> there is no way of knowing how they went about the process.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
--20cf30433dfe0bb29f049ac2c429
Jonathan put one in the Repository IB
Art
On Jan 26, 2011 9:45 AM, "MARK COLLINS" <markc@myfastmail.com> wrote:
>>>Have you checked the permissions on oninit itself? It should be
>>>root:informix:6755 or root:informix:6754 - the 4 is as-shipped, the 5 is
>>>OK.
>
> Didn't there used to be a utility or shell script or something that would
> check owner/group/permissions on all of the Informix components, to
validate
> an install?
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
--20cf3054a54733a0dd049ac2e0db
On Wed, Jan 26, 2011 at 08:35, MARK COLLINS <markc@myfastmail.com> wrote:
> >>Usually, /tmp should have 1777 permissions - the sticky bit should be set
> >>so that someone other than the owner (or root) without write permission
> >> on the file should not be able to delete it.
>
> There is no sticky bit set at this time. The permissions block in ls -ld
> /tmp
> shows drwxrwxrwx. Would that prevent the procedure from creating the debug
> file?
>
This is a problem on your system tangential to the one you're running into.
It gives people more free rein to delete files than is desirable - anyone
can delete anyone else's file.
It does not affect the behaviour of IDS>
> >>Have you tried creating the file before running the procedure?
> >>
> >>In the circumstances, 666 permission might be appropriate for the test
>
> I didn't mention that, but yes, I did try creating the file, using 'touch'.
> I
> don't recall if it was 666 or 777 permissions, but I still got the error.
>
Not unreasonable - given what's below, expected in fact.
> >>Have you checked the permissions on oninit itself? It should be
> >>root:informix:6755 or root:informix:6754 - the 4 is as-shipped, the 5 is
> >>OK.
>
> Hmm, that's different. I have:
>
> -rwsr-sr-- 1 informix informix 7436702 Feb 8 1999 oninit
>
> Can the informix:informix ownership be part of the problem?
>
This is the 'root cause' of the trouble, if you'll excuse the awful double
entendre.
Fix this and you will likely find some (maybe even many) of your problems go
away.
> >>The 1 EPERM "Not owner" suggests that the server was not empowered to
> >>create the file, or (more likely) not empowered to change ownership on
> >>the file - hence my question about the permissions on 'oninit'.
>
> The error occurs whether the file exists or not, so I don't think it's
> anything to do with changing ownership. And, since /tmp has 777 (not 1777)
> permissions, it seems that anyone should be able to create the file.
>
Agreed.
> >>If there are permissions problems, they could have been created when the
> >>reversion from trusted to non-trusted occurred.
>
> That was one theory proposed by the current Unix admin. Unfortunately, the
> reversion happened many years ago, and the people who did it are long gone,
> so
> there is no way of knowing how they went about the process.
>
Life happens.
--
Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
--001636c5b45fa2de08049ac34999
I dont know anything about procs but was wondering if you can omit the set debug file to "/tmp/test.trace and see where the default file ends up ? On out hp system we have drwxrwxrwt 7 root root 8192 Jan 27 11:30 tmp No problems with any user writing to /tmp