Re: compile+link Fujitsu Linux

On Tue, 5 Feb 2008 11:29:58 -0800 (PST), Richard <riplin@xxxxxxxxxxxx> wrote:

On Feb 5, 6:52 pm, Robert <n...@xxxxxx> wrote:
On Mon, 4 Feb 2008 00:04:01 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
On Feb 4, 7:35 pm, Robert <n...@xxxxxx> wrote:
On Sat, 2 Feb 2008 21:33:22 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
Others reached the same conclusion, which is why dynamic program structure is THE NORM in
the Unix and Windows worlds.

I am not sure why you are attempting to change the way that I (and, it
seems, Charles) have been working for years. The way I do things
things works 100% safe and reliable. You cannot claim anything better
than that, _plus_ I get flexability thay your mechanism doesn't give.

I wasn't trying to change your way of doing things, I was answering Charles' question.

When I looked at Charles question _I_ saw that it contained the
requirement to get CALL/CANCEL working. _Nothing_ that you have
suggested has been to meet that requirement.

The problem was Called Program Not Found. I suggested telling ld where to find it.

I was was doing batch jobs then maybe I would do that, or even
static. But I don't so what batch jobs do is of no interest.

In my world, Cobol are nearly all in batch jobs. User interface is in Java or occasionally
PowerBuilder.

That may be why your suggestions don't match the requirements.

Charles was unfamiliar with Fujitsu on Unix. I suggested the NORMAL Unix way of binding
programs .. for all languages, not just Cobol.

dynamic link structure Cobol style Load On Demand

Exactly, they are _loaded_ dynamically. The requirement was stated as
being the last: "dynamic linkage" which does dynamic loading. You
should have noticed that the DLOAD directive was used and thus the -l
was inappropriate (see table in manual).

Fujitsu works with DLOAD and dynamic program structure, because dlopen() finds programs
already resident. If the program is NOT resident then it loads from disk. The only
downside is Fujitsu will not CANCEL programs bound at start up time.

No. The downside is that the user has to completely close the
application, update the libraries, and then restart the application if
a new program, or an updated one, or a one-off, is required.

An application can do that with versioning. If it calls foo.1.3 and foo.1.2 is already in
memory, the loader will not use 1.2, it will load 1.3.

<shrug> I don't need multiple concurrent versions. The way I do it
works 100%.

The benefit is that you won't accidentally get a library installed by another application.

I never will because all my files are held in a structure of
directories that will never be used by anything else.

Why do you keep coming up with entirely spurious arguments and straw-
men ?

YOU brought up replacable files as an advantage.

Your claim was: "The benefit is that you won't accidentally get a
library installed by another application.".

In what way does _your_ mechanism do this ? If you libraryize your
programs and version them what is it that prevents another application
choosing the same name and having the same version and 'accidentally
installing that over yours' ?

One library file is less likely to be overwritten than one of several hundred.

If it IS overwritten, the program will not start, because entry points will not match.

You make claims about what may happen and seem to completely fail to
notice that the same problem could occur to your system. You claim a
completely spurious 'benefit' for your mechanism without knowing what
my mechanism actually is.

I know how dynamic Cobol calls work.

Version binding is normally done by the linker; it is normally not coded into the calling
program, thus you don't have to recompile the caller to change its binding, but you do
have to reload it. However, versioning can be controlled by the program by using the
dlvsym() function.

Why do you think that relevant ? I haven't recompiled 'the calling
program' for years.

If you're feeding it the program name via database, you could just as easily give it the
version string. That wouldn't require a recompilation either.

And I could even more easil;y just continue to use what has worked
well for me for decades without your unwanted complexifications.

We Have Always Done It That Way (WHADIT).

Sounds like a golden opportunity for hackers.
mv login.so login.bkp
cp mylogin.so login.so
echo Ready for unauthenticated login.
....
mv login.bkp login.so

The users would _also_ need to have access to a compiler and to the
specifications of the framework, or the source code of that, to know
what 'mylogin' must do when a user logs in.

It's probably returning user and group in a structure. Write a stub to call it and look at
the structure returned.

You may as well claim that "anyone can write their own Unix login and
get root access".

No, but you'd be amazed at the percentage of systems where that's not necessary, because
they still have default logins.

What makes you think that users have write access to the program
directory ? _I_ can drop in another program.

If they have read access, they can copy your whole directory structure to their home
directory, change permissions all they want, and run their local copy to find out the
boss' salary.

Well, actually, no they couldn't. I already told you that particular
programs can be set to be owned by the application administrator with
a group id of the trusted group and permissions of 640. It is only if
you are a member of the trusted group that give read access to run (or
copy) that program. Users can be members of several groups so access
can be very granular. Users not a member of that group will get a
'program not found' if they try to select it from the menu.

I assumed the files had world read permission. You stopped that approach.

If the library was required at start up (as in your mechanism) then
the application would fail to do anything for users not in _all_ the
trusted groups. Also you gather several programs into one library so
you have less, or no, usable granularity.

Granularity is in the called programs. It doesn't matter how they are packaged.

My mechanism is oriented around data, not programs. If I want to protect month-end figures
in the accounting system, for example, I protect those numbers in the database.
Unauthorized users cannot change them by running the monthend program, by writing their
own program nor by running a database utility. Your notion of security by controlling
access to programs was obsolete twenty years ago.

Just change the subject then. You were trying to say that using
libraries was 'more secure'. You tried to say that 'home-grown' was
not secure.

Now you just change the subject to something different because you
failed to establish your unsupported and flawed assertions.

YOU introduced application security, not I.

No, that is wrong. I was saying that "the CALL dataname feature is
invaluable ..".

Then, out of the blue, you changed this to: "Now you're advocating
home-grown security."

You said "invaluable as it means that the menu program can use a data file to define what
is available in a particular application, or even to the particular user." That's
application security, and is irrelevant to dynamic loading. You could do the same if all
programs were in one library.

Security belongs in the called program, not the menu program. A user could write his own
program that calls the yours. Actually, security belongs on the protected data, but that's
another topic.

In fact my system does implement field level security within the
system, but I don't run Banks or Stock Exchanges. The level of
security that I use is exactly correct for the businesses that use my
applications.

I worked with a system admin whose first job, after getting a degree in computer science,
was night manager at a Wal-Mart, where he ran the back-office computer. When the help desk
was talking him through a problem, they were giving him the root password on THEIR SERVER.
He knew exactly what that meant. He said, "What a gaping hole. I could have done
anything." He didn't; someone else might have.

The relevance of this little anecdote is ?

The moral is: don't assume users are too dumb to hack your system.

If I DID want to limit access to a program function, the security check would be in the
function, not the file it is packaged in nor the calling program. Relying on Unix file
system to do application security is weak. For example, if the setgroupid bit of a program
file is set, it executes under the owner's group id rather than the user's.

Another straw-man. Why would I have setgroupid set ?

Because a user set it.

Excuse me, but how did a user get to set this ?

He would have to trick someone in the group to set it. Are priviliged users' .profiles
world writable? Is root's? How about shell logins?

.

Relevant Pages

  • Re: compile+link Fujitsu Linux
    ... just as Charles reported. ... In the late '90s POSIX became the Unix standard. ... LD_LIBRARY_PATH is used to load dynamic libraries at run time. ... can 'front end' the search path. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... the Unix and Windows worlds. ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... But I don't so what batch jobs do is of no interest. ... Security that depends on user ignorance is so 1980s. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... the Unix and Windows worlds. ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Security that depends on user ignorance is so 1980s. ... libraries was 'more secure'. ...
    (comp.lang.cobol)
  • Re: RWW Security was compromised.
    ... Windows server security as my previous experience is Unix. ... > One of our clients RWW was compromised over the weekend. ...
    (microsoft.public.windows.server.sbs)
  • Re: What protects Unices from Virus like attacks ??
    ... >> what protects all Unix machines from such similar problems. ... > If a vulnerability is found for Unixen, ... I met security engineers that were aghast at some of the ... Many MS customers don't know what to do ...
    (comp.unix.questions)