HP3000-L Archives

November 1996, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Carl Sitherwood <[log in to unmask]>
Reply To:
Date:
Mon, 11 Nov 1996 16:29:05 -0500
Content-Type:
text/plain
Parts/Attachments:
y (63 lines)
   Jeff,

   I ran into the same problem here and simply entered the shell, did a chmod
   on the file and was able to get in.  I forgot to pursue it past that so I
   don't know the details.

   Carl
   HP Atlanta


______________________________ Reply Separator _________________________________
Subject: Strange file access problem...
Author:  Non-HP-HP3000-L ([log in to unmask]) at HP-USA,mimegw1
Date:    11/8/96 12:50 PM


Here's a strange one that cropped up this morning.  We have a KSAM file
(CM KSAM) that resides on a specific group which other users, not in
that group, cannot access.  Specifically the file attributes were:

> SECURITY--READ    : ANY    (keyfile and datafile the same)
>           WRITE   : ANY
>           APPEND  : ANY
>           LOCK    : ANY
>           EXECUTE : ANY
>         **SECURITY IS ON

Account security:
> SECURITY--READ    : AC
>           WRITE   : AC
>           APPEND  : AC
>           LOCK    : AC
>           EXECUTE : AC

Group security:
> SECURITY--READ    : AC
>           WRITE   : AC
>           APPEND  : AC
>           LOCK    : AC
>           EXECUTE : AC
>           SAVE    : AL, GU, GL

User's attributes (homed to another group in the account):
> CAP: ND,SF,BA,IA

The file is opened for SHR;LOCK access.  The user was running a COBOL
program which opens the file for input.  It returned a file-status item
starting with a '9' meaning an MPE error, and CKERROR gives the MPE
error as 93 which I presume to be an FSERR 93, security violation.

Neither the failing user, nor users of the file's home group are the
creator of the file (which is MANAGER).  There were no ACDs on the file.

I could not work around this without :RELEASEing the key/data files.
Why?  What would prevent access to this file?  The closest duplication I
could find was opening it without ;LOCK which results in a fserr 48 (I
think it was) and not an fserr 93.

This is the strangest thing I've seen in a long time (that I can't
explain *somehow*).

Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2