[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #TXX-128658]: security mcidas

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [McIDAS #TXX-128658]: security mcidas
  • Date: Fri, 01 Feb 2008 08:06:30 -0700
Hi Martin,

re:
> onder welke user draait dit process ?

The McIDAS ADDE remote server runs as the user 'mcadde'.  If one follows
the Unidata recommendations for McIDAS installation and configuration, the
'mcadde' account will:

- not allow logins
- share the same $HOME directory as the user 'mcidas'
- be in the same group as the user 'mcidas'

A high level overview of the process that is followed for an ADDE
transaction is:

- the client application contacts the remote ADDE server using
  the registered port 112

- the Bourne shell script ~mcidas/bin/mcservsh is run

- mcservsh reads the file ~mcidas/.mcenv to set environment variables
  that are needed for the McIDAS session that will be created to
  service the client request.  Part of .mcenv is a CD to ~mcidas/workdata.

- after sourcing .mcenv, mcservsh execs the top level McIDAS server
  routine ~mcidas/bin/mcserv

- 'mcserv' reads the first part of the client request to determine
  what type of data is being requested.  It then execs the appropriate
  top level server for the type of data (IMAGE, GRID, POINT, TEXT, NAV)

- the type-specific top level ADDE server reads the client request to
  determine if it can fulfill the request, or if it needs to exec a
  subserver.  For instance, the top level ADDE server for IMAGE data
  knows how to serve imagery in AREA file format.  Datasets that
  are in a different format like GINI or NEXR are handled by subservers.
  If the type-specific top level ADDE server can fulfill the client
  request, it does so and exits.

- if the type-specific top level ADDE server could not fulfill the
  client request, it attempts to exec a subserver whose name.  If
  this fails, the server sends back a status message and exits

- if a subserver was execed, it reads the client request and tries
  to fulfill the request.  If it can, it sends back the data requested
  and a status message and exits.  If it can not, it sends back a
  status message and exits

- all along the way, a bogus request will result in a server sending
  a status message and exits.

I hope that this overview of how ADDE works helps...


Cheers,

Tom
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: TXX-128658
Department: Support McIDAS
Priority: Normal
Status: Closed