Conference 7.286::digital

There is no company-wide policy on this.

It took much effort to get the words "with proper consideration of employee
privacy" added to the "Proper use of DEC Computers..." policy; my specific
intent in pushing this was to make it clear that managers should not be
reading their employees' mail in order to be sure that systems aren't being
misused.

At Spitbrook, V.P. Bill Heffner has issued a memo which states that the misuse
of privileges to examine private files is exactly the same as rifling through
someone's desk, and is grounds for immediate dismissal.  And people HAVE been
dismissed.

/john

    I'd like to ask a question about the topic in general.  Who can
    read your mail.  With VAXmail, it's obvious... anyone with SETPRV
    on YOUR node.  How about with the 'corporate' mail system, MTS?
    With the multitude of message routers your message may go thru,
    is there a chance your mail could get looked at?  I surely don't
    want a 'zealot', perhaps a cousin of the person trashing Digital 
    Reviews out of the mailroom... to see some of the mail I send...
    
    bill

    I agree with .1
    
    Using privs this way is a gross misuse of privilege. Might as well use
    a crow bar and force the lock on my desk. Same thing. 
    
    I would suggest that if there is a need for a 'common' mail file
    as is the case in .0, then a mail file can be created for that purpose.
    It can be placed in a common directory and protection can be set
    accordingly. At least then everyone known that anything placed in
    that mail file is "public" property.
    
    Another suggestion is that sites make use of the SECUREPACK package.
    This package makes use of the various security features in VMS and
    provides a daily report to the system manager listing all file accesses
    for which privilege was used. It does not prevent access, but at
    least it lets you know that it has taken place. You can then go
    and inflict pain and suffering on the culprit.
    
    Finally, can anyone post a copy of Mr. Heffner's memo here, or tell
    me where I can obtain a copy? I work in ZK and have never seen it?
    
    
    /Mike Grossmith
    

This is not an exact match to this subject but seemed appropriate while I was 
writing it.

309.2 reminded me that once, while cleaning out the default [DECNET] 
directory, I found a lot of .LIS, .TXT and other files that didn't seem to
belong there. 

The files were named TTI2.LIS, TTI0.TXT etcetera. They came from people on 
other systems using local print devices attached to our terminal queues. To
print the file from the remote system the command would be: 

        $ COPY filename.ext SYSTEM::TTI0:
                                       ^
If you didn't put the ":" after TTIn, a file called TTIn.ext (defaults to
input extension) created in [DECNET]! The file would mysteriously not get
printed. 

This is world readable to anyone coming in over the network!

I have found some highly confidential material that way.

BTW - From MAIL the command would be something like:

        MAIL> EXTRACT SYSTEM::TTI0:

A word to the wise...

        Mike

Here's some "good news and bad news:"

From "System Abuse Reporting System -- Guidelines for Reporting and
	Investigating System Abuse" -- Digital Security, February 1987

p. 6:  Unauthorized Access ...  If an employee's mail account was accessed
	and there is a good possibility of identifying the person responsible,
	there should be a local investigation.  If the access was to an account
	which contains new product information there should be a corporate
	investigation.

p. 20: Inspecting a User Account     Digital authorizes accounts on its
computers for employees to use in support and as a tool in the performance of
their job.  These resources are Digital assets.  As such, the company and its
AUTHORIZED agents, have the right to inspect the way these resources are being
used.  However Digital respects its employees and the work they perform in
support of Digital's goals.  Therefore the decision to inspect a user account
must be taken seriously and only within company guidelines.  ...  Both the
technical and security representative should be present.

        A while ago in a previous job I was confronted with the following
        dilemma:
        
        An engineer who reported to me was a system manager (with all
        of the appropriate privileges) on a particular system. In the
        course of his official duties (he was repairing a corrupted
        disk structure) he dumped  person A's (in our department, but
        not reporting to me) mail file. In that mail file he discovered
        information about person A and another person (I will call
        him B) in the group.
        
        The information was in affect that the two people were having
        an affair. Person A reported to Person B. This information
        seemed to explain some of the strange things that were going
        on, (vis a vis various management decisions in the group)

        Finally, to my questions.
        
        If you were the system manager, what would you do?
        
        If you were the system manager's manager (if he/she told you),
        what would you do?
        
        Strange things can and do happen as a result of a person having
        the system privileges.
        
        Joe

    RE .5  the decision to inspect a user account must be taken seriously
    and within company guidelines <
    
    Now we're back to square 1. WHAT guidelines, please ?

    Regardless of company guidelines, standards, policies, or whatever,
    the standards of reasonable behaviour dictate that:
    
    1. You should never assume that any data you entrust to the network
    will be secure.
    
    2. You should never access someone else's data unless you have their
    permission.
    
    Richard.

>    < Note 309.8 by STAR::MEREWOOD "Richard, ZKO1-1/D42, DTN 381-1429" >
>
>    Regardless of company guidelines, standards, policies, or whatever,
>    the standards of reasonable behaviour dictate that:
>    
>    1. You should never assume that any data you entrust to the network
>    will be secure.
>    
>    2. You should never access someone else's data unless you have their
>    permission.

    Richard's view corresponds exactly with my own.  However, from the
    previous replies, it would appear that no company guidelines exist, and 
    that it's up to local judgement and opinion, which may differ from
    site to site.

    A government of men rather than laws.

    "1. You should never assume that any data you entrust to the network
    will be secure."

That's something that needs to get fixed! For a company that claims to have
"secure" software we sure have a lot of paranoia about things on our own
network and systems. 
    
    "2. You should never access someone else's data unless you have their
    permission."
    
Now that to me is the prime directive. It matches with "do what is right".

        Mike

        Re: .11
        
>    "1. You should never assume that any data you entrust to the network
>    will be secure."
>
>That's something that needs to get fixed! For a company that claims to have
>"secure" software we sure have a lot of paranoia about things on our own
>network and systems. 
        
        The security of our software has little or nothing to do with
        it.  Data on a network can only be considered secure to the
        degree that the following people are trusted: 
        
             -  Everyone with physical access all the nodes used
        	(including all routers that pass messages).
        
             -  Everyone with privileged accounts on the nodes used.
        
             -  Everyone with physical access to all communication
        	links that messages are sent over (especially
        	including Ethernet links).
        
        Any of those people can compromise data you entrust to the
        network.  I don't know of any actual problems, but that is a lot
        of people to trust when you send personal information over the
        network.  The `fix' is better security awareness of DEC employees,
        and a higher respect for private files and communications.
        
        					B.J. 

    Just an idea.
    Maybe the group who develops/supports VAXmail could find a way
    to encode/decode the data stored in your VAXmail files.  If they
    used a software key, only you would know the key (password) that
    could turn your vaxmail message into human readable text.
                        
    SET encode_decode_key = "abc123" 
    
    This way, even if someone has privs to access your data, finds a
    backup tape, uses your unattended terminal, etc.  They can not read
    your VAXmail.
    
    Now if you forget your KEY, even you can't read your mail.
    
    just an idea (I bet Oliver North would have like it...)
    Paul

Encryption of stored files is generally prohibited in the corporate environment
unless you register your key in some trusted and fire-safe place.

The exposure in terms of loss of information if an individual is run over by a
truck or resigns is too great to permit.

/john

        Re: .13
        
        Encrypting mail messages does solve many problems, and has been
        studied by many people (inside and outside of DEC).  However, it
        is not an easy feature to add.  Some of the problems are: 
        
          - If encryption is only handled on the node you use, then
            you don't reduce the number of people who can read your
            mail, you only make it harder for them to read it.
            
            For example, either your new mail is unencrypted until
            you login (and can be read), or the key is stored on
            the system (and the key can be read by someone with
            privileges who wants to read your mail).
            
          - If the mail messages are encrypted when they are
            transmitted, then people monitoring the communication
            link can not read your mail.  However, you then either
            need a separate key for everyone you want to talk to,
            or a public key encryption system.  (And public key systems
            have keys that are too long to memorize and type in whenever
            you want to read a message.)
            
            And anyway, a privileged user could write a special front
            end for MAIL:  it would act normally, but save the keys
            you use and the messages you read and write in a file
            the privileged user could read later.  (This sort of
            attack is called a Trojan Horse program.)
        
        Encryption of information does protect information stored
        on backup tapes and transmitted over unsecured communication
        channels.  However, it does not provide security against
        anyone with physical access to the machine you use, any
        privileged users on the machine, or anyone with access to
        your unattended terminal.
        
        [But it does increase the level of expertise needed to read
        your mail and protect against spur-of-the-moment attacks.]
        
        					B.J.

How about this policy:

 6.24 Employee Conduct                                    04-FEB-85

EMPLOYEES ARE EXPECTED TO TREAT INFORMATION APPROPRIATELY.

For example, they will not:

   ...

   o Access computer files or give information to others to 
     access computer files when not properly authorized.

/john

    Well, that seems to cover it...
    
    R.

    re .6
    
    The answer to the moral dilemma is really quite straightforward:
    
    1. Fix the ISAM file as chartered
    2. Alert the Miami Herald to stake out Person B's house
    

    
    re .16
    
  	"6.24 Employee Conduct "  *seems* to cover it, except for one
    problem:    *Specifically*, what is "proper authorization" ???!!!???
    
    We're still back at Square One.
    
    The understanding here at WMO is that employee's accounts are to
    be treated like employee's desks.   No one is to romp through them
    without permission of the employee.
    
    -Don-

>>>Note 309.3  
>>>CSSE32::GROSSMITH "Mike Grossmith"                   6-MAY-1987 12:35
>>>                              -< Shoot 'em!!! >-

         We agree with you and in particular we are interesting on:
        
  ...  Another suggestion is that sites make use of the SECUREPACK package.
  ...  This package makes use of the various security features in VMS and
  ...  provides a daily report to the system manager listing all file accesses
  ...  for which privilege was used. It does not prevent access, but at
  ...  least it lets you know that it has taken place. You can then go
  ...  and inflict pain and suffering on the culprit.

 
         from where we can get it?
         
         Thanks,
                Gianni & Umberto

>  ...  provides a daily report to the system manager listing all file accesses
>  ...  for which privilege was used.

Hogwash.  It does no such thing.  It just creates a log of when someone with
privileges logs in.  So you get a log of everytime the system manager logs in.
There's nothing in the log to indicate what files were accessed.

/john

    .20   There is a SECURPACK notesfile at ANCHOR::SECURPACK
    
    .21   Hogwash yourself.  SECURPACK has a memu of options that allow
          a system manager the opportunity to effectively use existing
          VAX/VMS security features.  One of these features is setting
          alarms (via ACLs) on selected files given a particular access
          status, i.e., successful access, unsuccessful access.  Granted
          that you don't need SECURPACK to set ACLs, but after using
          SECURPACK for almost three years now, the ease of using the
          memu options and the daily reports makes the task of monitoring
          information security infractions a much easier task.
          
          The SECURPACK notesfile is a good place to find out more about
          the product in addition to providing input for enhancements.
    
    Ken Patterson
          
    

    As with all issues involving the law, there are no hard and fast
    rules.  That's why we have judges, lawyers, and managers.
    
    I like the general statement made by the V.P. in reply .2.  That
    about covers it.  Although no one can state exactly under what
    conditions and employee's desk can be searched, there is a LOT of
    law, decisions, and general experience on privacy in the context
    of an employee's desk in an office.  Most courts, when confronted
    with a novel or unfamiliar situation, defer to "commonly acceptable
    practice".  For example, if a case comes up involving a medical
    practice, or a teacher's behavior in the classroom, the court will
    frequently circulate the case to many "acceptable experts" in the
    field in question and ask what they would do under the circumstances.
    This becomes the "commonly acceptable practice".
    
     In the case of breaking into a desk, most people agree on what
    is ethical and legal and what is not.  By making computers equate
    to desks, then the principles involved are transferred.
    
    Suppose you accidentally come across something?  (Through the misplaced
    file examples, etc.)  The law is clear here, also.  If you pass
    an office and find someone dead drunk on the floor, then you can
    report it without being accused of "breaking and entering".  It
    was not your INTENT to search out the condition--discovering it
    was an accidental by-product of a legitimate action.

>       One of these features is setting alarms (via ACLs) on selected
>	files given a particular access status, i.e., successful access,
>	unsuccessful access.

Any ACL which would cause an alarm on access to a mail file by someone with
elevated privileges would also cause an alarm everytime the file was accessed
for any other purpose.  (Everytime mail was delivered and everytime the user
read mail.)  The alarms would then be ignored.

/john

As well as the guidelines already put forward or quoted I would like to add
one more.  This will probably cover the case about A and B.

	Any information unintentionally obtained which was not intended
	for the recipient must be regarded as privileged information and
	must not:

	    - be disclosed to any third party without permission of the
	      owner of the data
	    - used for any purpose by the accidental recipient

In other words, act as if you never saw it.  I would however think that if
you uncovered evidence of criminal activities or activities that violate
corporate policies that the attention of an appropriate manager be drawn to
the fact.  If absolutely necessary I would think it best to do this by the
"I have heard rumors that ....."

jb

    I agree with .25 -- If a person accidentally come across data that
    they're not supposed to see then they should forget what they saw.
    If there's a reason that it can't be forgotten, I should think that
    the next best thing is to tell your manager what happened. Come
    to think of it, maybe you should do that anyway in case people later
    come to believe it wasn't accidental. You don't necessarily have
    to say what you saw, just that you saw it...
    
    Richard.

    Those of you debating whether or not Securepack (or an ACL) would
    be useful in catching someone abusing privileges to read a mail
    file have missed something pretty basic:  How do you think mail
    gains access to a user's mail file to deposit mail under normal
    circumstances?
    
    - M

    Was there anything wrong with this?
    
    I was with two other DEC employees one day, and we stopped to visit
    a former co-worker.  None of us had a pen handy to leave a note
    for that person (who wasn't in the cube), so person A pulled open
    the top desk drawer 3", took out a pencil, wrote a note, returned
    the pencil, shut the drawer, and we left.  Person B was very upset
    by this, and stated the policy about "not going through desks".
    
    I never would have thought of that as going through a desk!  I assume
    that going through a desk would imply more than looking at the pencil
    and pen selection. 
    
    But technically, I suppose it could be considered an invasion. 
    This person was a friend, so I didn't worry, but it made me realize
    how much so-called policies are as good as the individual's definition
    of them.

    Sounds like an over-sensitive twit.

    Well, I would have thought so too, but I once got in big trouble for
    borrowing a pair of scissors from the desk of our computer lab
    operator.  I now treat any closed drawer as private - if I'm looking
    for something like notepaper or a pen, and it's not clearly visible
    on the desk, I'll go somewhere else.
    
    I keep my own desk locked, anyway.
    					Steve

           <<< HUMAN::WRKD$:[NOTES$LIBRARY]SECURITY_POLICY.NOTE;2 >>>
                   -< Worldwide Software Security Policies >-
================================================================================
Note 48.0            The Feds and Privacy/Security Policies           No replies
VIDEO::LEICHTERJ "Jerry Leichter"                    55 lines  21-MAY-1987 22:22
--------------------------------------------------------------------------------

...

To: [email protected]
Subject: Re new Federal Email privacy act. This is important (from MIT)
Date: Tue, 19 May 87 05:40:08 -0400
Message-ID: <[email protected]>
From: Dave Farber <[email protected]>


	This is a copy of a letter published in MIT Tech Talk. Anyone who
did not read that memo should look read it. Be sure to note that
operators of electronic communication systems now have legal
responsibilities for the privacy of data. 


MEMORANDUM


To:         The MIT Community
From:       James D.Bruce, Vice President for Information Systems
Re:         The Electronic Communications Privacy Act


	The Electronic Communications Privacy Act of 1986 was enacted by
the United States Congress in October of last year to protect the
privacy of users of wire and electronic communications.

	Legal counsel has advised MIT that its computer network and the
files stored on its computers are covered by the law's provisions.
Specifically, individuals who access electronic files without
appropriate authorization could find themselves subject to criminal
penalties under this new law.

	At this time, we can only make broad generalizations about the
impact of the Act on MIT's computing environment.  Its actual scope
will develop as federal actions are brought against individuals who
are charged with inappropriate access to electronic mail and other
electronic files.

	It is clear, however, that under the Act, an individual who,
without authorization, accesses an electronic mail queue is liable and
may be subject to a fine of $5,000 and up to six months in prison, if
charged and convicted.  Penalties are higher if the objective is
malicious destruction or damage of information, or private gain.

	The law also bars unauthorized disclosure of information within an
electronic mail system by the provider of the service.  This bars MIT
(and other providers) from disclosing information from an individual's
electronic data files without authorization from the individual.

	MIT students and staff should be aware that it is against
Institute policy and federal law to access the private files of others
without authorization.  MIT employees should also note that they are
personally liable under the Act if they exceed their authorization to
access electronic files.

    I believe the factor that should be examined here is intent. If
    the intent is innocent, then no-one except an over-sensitive twit
    would mind one borrowing a pencil. This is my opinion, but I believe
    that it is based upon common sense.
    

    Re: .33
    
    I think that some people (most people?) view their desks as private,
    and resent the intrusion itself rather than what was actually taken.
    Consider how you'd like it if, while you were away, someone walked
    into your house to borrow a pencil?  (Assume door was unlocked.)
    
    I think the reaction described (and the one I encountered - mainly
    a complaint to my manager!) is a bit extreme, but I do now accept
    it.
    					Steve

I wouldn't accept .32 as necessarily applicable to a private business whose
electronic mail network is being operated for business purposes (with personal
use tolerated to the extent that it doesn't interfere with business use).

The provisions of the Act apply primarily to common carriers.  I don't believe
it was intended to be applicable inside a company.  Further, the act specifies
that employees of the electronic mail provider may access the mail in the
performance of their duties in operating the electronic mail systems.

MIT is a somewhat different environment; it provides computer services not only
for employees, but also for students (effectively customers).  This may have
made MIT's legal counsel feel that MIT had enough of the characteristics of a
common carrier to make the act applicable.

So, to repeat, nothing that an MIT legal counsel states about MIT applies to
DEC.

/john

	I browsed through this note's 35 replies and found no mention of
	the possibility that a desk drawer could contain a sensitive
	document inappropriate for viewing by others.  Though unlikely,
	an excess of informality could complicate disciplinary action,
	business confidentiality, or litigation.

	The visitor who opens a desk drawer to borrow a pencil could find
	thrust upon him a responsibility for confidentiality beyond the
	capacity of ordinary character.

	Personally, I class my crt screen as a document, and I remember
	which visitors lack the manners to avoid reading it.

	Also, were I to find anyone probing my office, I would ask the
	intruder to explain why I need not file a request that he be
	fired.

	Regards, Robert.

    Re: .36 (Private documents in desks)
    
    For some reason some people keep private documents such as pay check
    stubs in their desk drawers.  Just this past week I was standing
    in a manager's office talking with him and noticed that one of his
    desk drawers were open and a pay check receipt was opened in said
    drawer.
    
    I was all I could do to not look at the amounts on it.  Very much
    like not looking up the skirt of a lady while holding a car door.
    
    The point is that there is great potential for embarrassment on
    the part of both parties when doing some honest and innocent searching.
    
    It's very hard to avoid especially places where office sharing has
    been instituted.
    
    Don

    RE: .36
    It is precisely the attitude that you display that has made me decide
    to leave DEC after only 9 months.  In the short time that I have     
    been here, I have seen more empire building, CYA rearguard action,   
    and just plain pompousness, that I cannot equate "open door policy"
    or "employee development" or even - gasp - "matrix management" with 
    the glossy brochures passed out and glibly mouthed by so many individuals.

    This is a place where we all are supposedly working together.  We
    spend more waking time here than we do with our loved ones.  And
    yet, do we have to give them,  our loved ones a written note to
    put away our folded T-shirts!

    Your personal, and private documents belong where you personally
    and privately LIVE.  Not in your DECcube, or your DECdesk!
    
    Remember, those who live by the letter of the law can never spell
    justice.
    
    Chuck

>    	Personally, I class my crt screen as a document, and I remember
>	which visitors lack the manners to avoid reading it.
    
    Any document (or CRT screen) that I don't want visitors to read
    is removed from sight when they arrive. I consider it discourteous
    to place all the responsibility on a guest. If something is left
    in plain sight on my screen or desk then I would *never* fault anyone
    for reading it. [Sifting through things may be different]

>	Also, were I to find anyone probing my office, I would ask the
>	intruder to explain why I need not file a request that he be
>	fired.

    As yes the old guilty until proven innocent. Sorry, a foreign concept
    to me. But then I never keep anything that it would bother me to
    have another DEC person read in an unlocked drawer or unprotected
    file. As much as I like DEC it makes me consider getting someone
    fired a very serious punishment not to be taken so lightly. My office
    is right outside a large conference room. It would be foolish for
    me to assume that no one would ever drop in to borrow a pencil,
    a piece of tape, a staple or to use a phone. As long as the phone
    call was for business, none of the above would bother me very much.

    It would take a lot for me to jump to the conclusion that 'bad things'
    were taking place.
    
    		Alfred

>    Your personal, and private documents belong where you personally
>    and privately LIVE.  Not in your DECcube, or your DECdesk!

What about private documents that relate to the business ofthe company?  Don't
they belong in my DECcube or my DECdesk!

Of course they do.

What about personal communications with people over the DECnetwork?

I'm sure you understand.  Good luck elsewhere.

/john

	.40 clarified at least partially what seems a misapprehension in
	.38 with regard to my .36 -- if you can remember what's where here.

	.38 notes problems of confidentiality with respect to personal
	documents.  I agree that personal documents don't belong in one's
	office, though it's likely they will pass through occasionally and
	ought to be afforded at least the respect they would receive from
	guests in one's home.  Also, I wonder whether liability for their
	misuse rests with the company.  In some places, employees have
	lockers.  Are our offices the ame as lockers?  Is our email the
	same as a locker?

	My point about strict security of office contents (and email messages,
	of course) rests more upon business matters, as .40 illuminates.  For
	example, I should be embarrassed to glimpse a folder in a manager's
	desk labelled "Discipline procedure" with someone's name on it -- not
	likely, but better not to look.

	Incidentally, .38 also comments "This is a place where we all are
	supposedly working together."  Remember, this is a place that employs
	100,000 people, almost a representative sample of the population at
	large, and we know what that implies.  Surely as most of us rigorously
	respect office privacy, others do not: better to keep sensitive
	information sealed.

	In any case, I shall remain disappointed with persons who lack the
	gentlemanly reserve to remain uninformed of the contents of my office.


	Regards, Robert.

    John,
    I do understand, but also, look at it this way, I am privy to
    information that many periodicals would be interested in due to
    my use of Notes.  However, DEC trusts me enough to not divulge this
    info even after I leave the company.  So why is it that what is
    in a person's desk must be of more value than all of the other info.
    
    Also, my main point of contention was the statement about having
    the person fired.  Whatever happen to good old-fashioned " Excuse
    me, can I help you rummage through my desk?" :^)
    
    Anyhow, thank you for the best wishes, I will take them in the spirit
    they were offered, and at the same time, good luck to all of you,
    and don't let anyone ever take notes away from you all!
    
    \Chuck

>   So why is it that what is in a person's desk must be of more value
>   than all of the other info.

This is an absurd question.  What is in someone's desk might be more sensitive
than anything in a notes conference for any number of reasons:

    1. A discussion of individual employee performance.
    2. A salary plan or a paycheck.
    3. An unannounced product that even you don't know about.
    4. A job offer from another group which the employee and his
       manager have not yet announced.
    5. A memo from Ken Olsen, not for general distribution.

And so on.

/john

>>  This is an absurd question.  What is in someone's desk might be more sensitive
>>  than anything in a notes conference for any number of reasons:

    Another ABSURD question, why not lock your drawers??
    
    I'm sure you will have a GOOD response!  But don't worry, god SOLUTIONS
    will als be accepted.
    
    Chuck :^{
    

re .44:

>    Another ABSURD question, why not lock your drawers??
    
Like VAX accounts which can have their passwords changed by a manager 
wishing to enter your account and read your mail, desks have locks with 
numbers which match keys with numbers which can be obtained very easily
(and duplicates are often kept anyway). But this is irrelevant as in 
principal it should not be done without good reason and without someone 
from personnel or security present.

Dave.

>    Another ABSURD question, why not lock your drawers??

When I've just gone to lunch?

/john

    Re .46
    
    That all depends on whether or not you take a two hour lunch. At
    Shrewsbury everyone is required to see a series of four videotapes on
    security. One of the many things mentioned is if you are away from your
    desk for more than two hours your desk top should be cleared of
    sensitive material and the desk locked.
    
    			Fred
    

    [Re: .36]:
    
    > ... I remember which visitors lack the manners to avoid reading
    > [my CRT screen].
    
    Hey, buddy, quit lookin' at my wife!
    
    This suggests a method of weeding out undesireable employees.  Put
    some bogus but juicy data on your screen, have people come in on
    some pretext, then watch their eyes.  If they look, fire them. 
    Never mind that some types of CRT displays (blinking, for instance)
    are actually physiologically hard to turn away from.
    
    Seriously, as someone who has put paychecks into other peoples'
    desk drawers, opened desk drawers looking for pencils, and stared
    at others' CRT screens (wishing I had the hardware they had), I
    guess I react negatively to the attitude expressed in .36.  If I
    don't want a visitor to look at my screen, I'll clear it; if I don't
    want them to look at the papers on my desk, I'll put them away.
    
    I agree that there are limits, though.  I have been highly annoyed
    to see people come into my office looking for a telephone.  I've
    heard of cases where someone desperate for a working terminal actually
    TOOK someone else's.  And if I caught someone rifling a desk, I
    would report him.
    
    As to the base note topic, reading someone else's mail should be
    considered a serious offense, so long as it's not because you're
    stupid enough to let it sit there on your screen).

  Has anyone been involved in a classified account - with the military?

I was a Classified Account manager for our operations group in the Air
Force.  You can't believe the Red tape, procedures, and reporting that
was required for the security of one file cabinet and its contents.

  Believe me, we don't want to get into procedures and specifics on electronic
information access.  Once started, procedures and Red tape could go on forever.
I believe DEC's "Do whats  right" credo is enough. Lets be gentlepersons,
respect privacy, use deplomacy, and keep our operation simple and friendly. 

    	I have a friend who works for Shell Oil.  Whenever she leaves the
    office she must lock all work away and all drawers & cabinets in her
    office.  The local security folk come through now and then and leave
    little orange "security violation" stickers everywhere they find so
    much as an unauthorized pencil out of place.  Receiving too many of the
    stickers over some period goes in your personnel record. 
    
    						--Doug

    A late addition to the discussion...
    
    I know of a manager who uses the desks of all of her reports as
    though they were her own.  No pen is safe, no unattended terminal
    is inviolate...if she thinks of a reason to set host, you are
    temporarily out of business.  It's completely unmalicious, but it's
    there. Her reports never leave anything personal anywhere on or in the 
    desk, and anything business related that is remotely confidential they put
    away except when actually using it.  
    
    With examples like this, why be surprised that less scrupulous types
    would take similar action?  Too bad we can't just eliminate secrets,
    then nothing would need protection!  But that's unrealistic in the
    real world.  

       
       
       	Sounds like this "manager" needs to be re-educated by her manager
       	on privacy in the office enviroment.  Myself, I'd be agast if
       	my manager came in and started ransacking.
       
       	I'd take the going thru of my stuff as harrassment and would take
       	action..
       
       							mike

    Just what type of action would you take?

  No need to consider it harrassment if it doesn't appear to be malicious.  Just
calmly block the opening of a drawer the next time the manager wants to open it. 
When the manager gives you a funny look "Why are you doing that", you suggest
that what is in the drawer is private.  Then you have a long discussion wherein
you describe personal privacy and how you haven't been granted it in the office.

  Properly presented, any rational person will catch your drift.  If not
rational, there isn't much you can do except to go over the manager's head or
get nasty.  I wouldn't suggest the latter.

John

       RE: .53
       
       I'm quite rational Michael. I'd start out with exactly what John
       has stated in .54.  IF that didn't work then a discussion with
       his/her boss would be started. Needless to say, it would take an
       exceptionally ignorant person to not catch my drift the first time
       and have me resort to the latter.
       
       						mike

    Once upon a time, and long ago.... (but at DEC)
    
    Someone was notorious for looking through other people's in/out
    baskets in the middle of the night. A manager who got pissed by this,
    typed a memo to a vice president with many negative evaluations of the
    snooping employee. He left it in his in basket, just as though his
    secretary had left him a copy of a real memo.
    
    The next morning, the employee came in early (read "on time") and
    flamed to this manager. The manager just sat there and grinned!
    
    [Note--both employee and manager are no longer at DEC, having left
    many years later.]
    
    Similar sorts of techniques can be used to discourage snoopers.
    [Of course, be careful as to what you say so that you don't create
    hassle for yourself.]

    Mike -

	Ignorance isn't the issue here.  If the person doesn't catch
    your drift, it may also be because he/she doesn't WANT to.  In which
    case, if you proceded "up the ladder" you may find that person
    supported by his/her higher ups.  The Open Door policy is nice on 
    paper, but with the hierarchical levels in DIGITAL, it's often
    buffered.

    Anyway, my experienced 2 clams...

    Michael,
    
    	Fortunately, I think I have higher ups who would support me.
    	
    	Fortunately, I also don't have to worry about the problem.
    
    							mike

I had an incident in my account and maybe someone can shed some 
light on policy or any so called accepted practice.

We the users, have been getting a hard time about changing our process 
names. Usually your process name is the same as the user name but 
sometimes even VMS changes your process name to things like LTA1234:. 
Some of us put a line in the LOGIN.COM to change it to something 
inoffensive. Attempts to get people to knuckle under with statements 
like "It is against policy" failed. Someone in operations entered my 
account and changed my LOGIN.COM. The old version was immediately 
deleted.

I was never notified either before or after the intrusion into my 
account. At least the creation date will help pin point which 
priviledged person or group (see below) was on the system at the time.

I have read all the previous comments about reading mail, etc. Reading 
mail is one thing, catching them is another. This incident proves 
beyond a shadow of a doubt that someone was into my account. It 
doesn't prove who because they have several priviledged accounts with 
dozens of people who know the passwords for those accounts.

Any comments/policies about changing process names? 

dmm 
    

    Process names for interactive users mean absolutely nothing to anyone!
    There is no effect on security, or anything else.  As far as I know,
    the only time process names are used for ANYTHING is in sophisticated
    task-to-task communications systems that have nothing to do with
    interactive users.
    
    Prohibition on changing process names is tantamount to regulating the
    cologne you wear.  Even worse, because the cologne has more potential
    for offending someone than the process name, and the process name has
    less impact on anything remotely related to reality. 
    
    Prohibition on changing process names is by far the most ridiculous
    thing I have heard of in my life!  This has to tbe the ultimate
    nit!
    

    I'm not big on reading policies, but I understand that manipulating
    someone's account without their knowledge if forbidden somewhere.
    
    I am fairly certain there are extreme penalties for mail tampering,
    but I don't know about tampering with accounts in general.
    
    At any rate, its a very unprofessional and cheap thing to do.
    

    If the LOGIN.COM was in an account that only YOU have access to
    (i.e a personal account) then changing it was the same as opening
    up your desk and changing the contents.
    
    I would consider it a breach of my personal belongings and would
    definitely AT THE MINIMUM warn the person that this is unacceptable
    behaviour. If that doesn't work, escalate it.
    
    Please be aware that as a system manager it sometimes becomes
    necessary to change individual files when something changes that a 
    lot of users have "hardwired" in their files. In this case it is
    easier to make the change and then notify the user as opposed to
    notifying the users and then waiting for the calls from those who
    don't know how to make the changes.
    
    There is NO excuse for changing personal files WITHOUT GOOD REASON.
    
    							Warren

       
       	A view from a system manager:
       
       	Frankly, I'm p.o.'d.  The ***ONLY*** time that system management
       (and ONLY system management) should touch ANY file in a "personal" 
       account is if it is affecting system performance to a MAJOR degree. 
       Example: Using the INQUIRE statement in a Network or Batch job can 
       cause infinte loops.  Changing a process name is STUPID and TOTALLY 
       uncalled for. I'd see this thru your management. Your files have been 
       violated. This is an uncalled for breach of privacy. There is NO
       policy on "process names" and I have ALL the policies concerning
       use of computer systems right next to me.
       
       I'd be livid and frankly, almost out for blood. This type of action
       must be corrected immeadiatly!
       
       							mike

    Sheesh!  What's the use of having system manager privileges if you
    can't use 'em!
    
    Don't get mad, get even!
    
    /Al
    

    Shouldn't this whole LOGIN.COM issue be brought to the attention
    of somebody in Corporate Security (or the appropriate group)?  I 
    don't think even going to straight to the source (your ops. people) 
    would resolve anything, since it appears that their way of thinking
    is pretty messed up in the first place...
        
    Have you asked them outright what their justification is for
    restricting changes to process names?  What was their response?
    
    I'm in total agreement with Mike Foley; I, too, was absolutely
    livid when I read your note, and have to admit that I read it
    more than once to be *sure* I'd read it correctly.  You really
    need to get this situation fixed.
    
    /donna
    

    $ SET FLAME/INTENSITY=SLOW_ROLLING_BOIL
        
    Just another couple of thoughts.  It appear to me that the 
    operations staff thinks they have unbridled license to do 
    *any*thing, *any*where on the system(s) they are responsible 
    for managing.
    
    Policies and procedures cited in earlier replies have stated
    that intruding into personal files is like browsing through
    someone's desk (agreed).  Granted, the equipment we work on
    belongs to the Corporation.  The files or contents of our desks 
    are nobody's business but our own, even though DEC owns the desk.  
    
    By the same token, our personal computer files are *also* nobody's 
    business, again, despite the fact that DEC owns the system.  
    
    A number of official memos have circulated that have stated 
    those same things.  I think the problem is that the operations 
    people think they're exempt from policy -- which, as we all know, 
    is *NOT* the case.  They think that since they are in charge
    of the equipment, they can do anything they want to what's in
    the system.  That's like saying that the people who are in
    charge of the furniture in our facilities can do anything they
    want to the contents of that furniture.

    Problems like this must be addressed.  Operations people don't
    walk on water, and they don't have the right to do the type of
    intrusion you've spoken about.    
    
    /d
    
    

       I hope you changed it back to what you wanted. 
                                                 Denny

    Matters between Digital employees should be handled at the lowest level
    of management possible.  Dragging in "Corporate Security" or
    "Personnel" without a full review by the people involved and their line
    management is almost always a big mistake.
    
    If something's changed about Digital that makes this impossible or
    turns every employee/employee conflict into a career limiting decisison
    for the aggrieved party, then corporate cultural historians, take note:
    an era is over. 

A few months ago DIS removed our ability to access DCL from the mail system 
here.  We had not "officially" had that ability for quite some time, but 
people were using loopholes, and DIS finally got around to closing the 
loopholes.  I was using, maybe 5000 blocks of non-mail-related disk space, 
so there could be no question of impacting system performance.  Over a 
weekend, DIS went into my personal directories in my account and deleted 
all DCL-related files, including (but not limited to) LOGIN.COM, a VAX 
Notes conference (business-related I might add) and other things.  The 
person doing the deleting must have not been exactly a technical giant 
because they deleted a whole bunch of stuff that was perfectly legal and 
that I used on a daily basis.  I came in on Monday morning to discover this 
surprise.  It was noon on that day before DIS managed to restore the 
erroneously deleted files and get me back in business.  I was told that DIS 
had every right to do what they did.

							Pat
    

    
    re .-1;
    
    No matter who the OPs people are (DIS or whoever) they must at least
    warn the user that their activites are a problem before taking action
    to correct them. For example, if your 5000 blocks was causing problems
    (some system are tight enough that it might be) then they should
    have talked to you about cutting down.
    
    We here in the MAA require several levels of approval before we
    allow someone access to another employees account. Sometimes this
    can't be avoided for both business and personal reasons. We also
    require a written justification be submited by the requesting manager.
    We in DIS are no different. If we need to access a person's account,
    other than to fix a problem reported by that person, we have to
    have the same type of justification we ask of non-DIS personell.
    It doesn't matter if you're accessing the account from within or with
    system privs.
    
    If a user has an offensive process name and refuses to change it
    then it shouldn't be the OPs people taking care of it. It should
    be that person's manager.
    
    Some people just take themselves too seriously and consider themselves
    the keeper of the rest of us. I've found that most of them step
    over that fine line and keep slapped because of it. The user's need to 
    complain when things like this happen. You also can't expect to
    see any external effects - most managers will support the OPs people
    to the users and do their scolding behind closed doors.
    
    -Ray
    

        I had a process deleted a couple weeks ago for using a process
        name that DIS folks didn't like. No warning, no explanation, just
        suddenly nothing at the other end of my terminal. I was in the
        middle of a fight with DIS on another matter, and was probably
        asking for trouble, but... 
        
        On another occasion a still nameless person complained to our
        system manager about my process name, and the system manager asked
        me to change it (it had something to do with my dislike for cats).
        After a couple weeks of badgering, I complied, only to have at
        least 3 people complain to me personnally asking me to change it
        back! 
        
        The bottom line is that no one is out there holding a gun to
        anyones head, forcing them to look at another user's process name.
        If you don't like what you see there, don't look there! 

    Good Grief!  I'm glad I'm the systems manager for our group ... someone 
    might be offended by VAX Notes personal name.

    On a more serious note, I'm concerned that there seem to be some people 
    that are:

        1.  taking themselves too seriously for the good of the corporation. 
            (Who knows what they'll do when their paranoia reaches its peak?)

        2.  wasting a lot of valuable company resources (their own time) on 
            utter trivia.  (If they're not blatantly offensive ... in 
            opposition to our "valuing differences" concept ... who cares 
            what personal names and, particularly, 15 character process
            name, are?)

    Sounds to me as though there a few really sick puppies out there ... and 
    they're violating some very basic rights to privacy.

    Terry

    
    I would rather like IS to upgrade all unsupported VMS systems
    { versions lower then 4.7 } to latest versions then waste time
    over completly idiotic issue of process names.

    Don't they have *anything* else to do ?

    			w.	

    Sounds like chicken-droppings to me. I'd ask for something in writing. 

    There's nothing like the fear of committing oneself on paper to
    make chicken-s****ers back off.

       
       
       	Now some bozo's are off deleting stuff?? Get your manager and
       their manager in a room and ask what GOOD stuff these groups have
       been doing for you.. If someone has the time to kill processes or
       delete files then they damned well have the time to upgrade their
       systems to new revs of software.. This is all VERY foolish.
       
       	Time to "raise the flag" and "work that issue".. (in DISpeak)
       
       							mike

Just to update everyone on what has transpired so far. I sent a 
mail to my manager. He then forwarded it to the MIS manager. 
IS Security was then called in. The individual was found and it 
seems that this was his solution to the problem because I didn't 
comply with his wishes even after sending mail to my manager. I 
have been told that this will not happen again without management 
escalation. Scratch one short cut.

If you have been hit by a MAC truck, DIGITAL does have a right to 
information in your desk or account if it's work related. Also a 
person could be under investigation but again it has to be done 
by someone in authority and not just by a system manager that has 
an obsession.

***************************************************************

A POLICY SHOULD BE BROUGHT IN THAT STATES IF FOR SOME REASON THEY 
HAVE TO ENTER YOUR ACCOUNT OR DESK THAT SOMEONE FROM SECURITY OR 
PERSONNEL SHOULD BE PRESENT TO MAKE SURE THAT ONLY WORK RELATED 
INFORMATION BE EXAMINED, TAKEN OR DELETED.

****************************************************************

This would make sure that someone was accountable and that any 
ZEALOTS out there can't use any pretense they feel like to enter your 
account or desk. As in other replys... if you don't play fair you don't 
play at all.

FLAME low.

How would MIS people like it if the bank that was holding their 
mortgage decided to enter their house one day and just wander 
around inspecting contents? SAME THING.

FLAME off.

We used to have a DCSC here. It was where we sold time on our 
systems to our customers. What would happen if a customer found 
someone from DIGITAL or another customer brousing in their 
account? Law suit time.



About the process name issue. Here are some excerpts from the 
mail I received about why I shouldn't do this terrible thing.

> A process name uniquely defines a User's process on our business 
> systems, and should project a sense of professionalism.

And yet VMS can change your process name to wonderful, 
professional things like LTA2315:

> Process names other than the system assigned process names, are not 
> required, and impede our ability to supply support to our users through User 
> Support and System Managers. 

Interesting though, in the last 3 years no one ever asked anything more  
than what is my USERNAME.

> If a User should wish to change their process name, the process name
> should "add value" to the name (such as system processes do), not detract from
> the information provided.

And yet VMS adds value by changing your process name to things like LTA2315:

> If a user's process name is set to something other than the standard, 
> it may indicate to the system manager that a Security violation exists,
> and the System Manager must investigate this. 

Yes this maybe true "occasionally" but if I was a hacker going in after
something, one of the last things I'd do is attract attention. Do you 
investigate every LTAxxxx:, etc?

> Audit trailing becomes more difficult when a System Manager must spend 
> additional resource time on tracing PID's to identify an unusual process name 
> to ensure system integrity and security.

Also a SHOW SYS only shows a process name of LTA2315: for my
process. This would STILL require the operator or system manager to
do a SHOW USER to confirm who in fact owns the process. All you 
require is to match the process name to a user name and not match by 
PID.

> With regard to System performance monitoring, process names get 
> recorded by performance and Security related software, and should be
> considered in that context as well. 

What is the difference if the process name gets recorded as Dave,
David, LTA2315: or RSX oldtimer as long as it's inoffensive?

We the users are customers to MIS. WHAT HAPPENED TO CUSTOMER SATISFACTION?

How does one go about charging one's wasted time with junk like 
this back to the cost center that originated the problem? That 
would put a quick end to people with idle time doing things like 
this.

dmm
    

       
       
       	Their "Reasons" are a load of horse-pucky. They obviously don't
       know what they are doing and have too much "free" time to do it!
       
       						mike

    
    Process names in VMS do *not* need to be unique.  It is possible
    for dozens of processes to share the same process name.  Any person
    or piece of software using process names to perform any sort of
    accounting or auditing is in error!
    
    If everybody understood that I think you would have less problems
    with people complaining about process names...
    
    					Rich
    
    btw, my process names are "King Arthur," "Sir Lancelot" and "Merlin",
    in that order...
    

     Re.  .76

          I fully agree with .77 and applaude the restarint expressed 
          therein.  The system mangler who sent those excuses is 
          either totally ignorant of some of the most basic aspects of 
          VMS or is trying to con management.  Either way, the s.m.'s 
          competency, professionalism, and/or ability to do the job is 
          seriously in question.
 
          In my own capacity as systems manager, I am consulted about 
          procedures, capital equipment expenditures, etc.  Sooner or  
          later this yo-yo is going to run into a manager who recognizes
          those statements relating to security, auditing, etc. for 
          the pure bovine excrement or ignorance that they are and find
          his/her head rolling for it.

          I didn't intend to turn the flame on, but I'll turn it off 
          now ... every user process name on a system can be the same.
          VMS complains ONLY when the user name AND process name of two
          processes TRY to be the same ... and then it says no, no, no, 
          no, no.

          Terry

    re: .79

>                  every user process name on a system can be the same.
>          VMS complains ONLY when the user name AND process name of two
>          processes TRY to be the same ... and then it says no, no, no, 
    
    The restriction is against different processes in the same UIC group
    having the same process name.  There are several ways to circumvent
    this, but most of them require elevated privileges (CMKRNL).
        

Normally, I do not reply to a note which I feel would not yield a 
productive return, but since this conference is about the DEC way of 
working, I'd like to make a contribution. After noticing the responses
which were generated by .59, I was a little depressed. 

I am not directly involved in the incident, but I am close enough to 
know a fair bit of the situation.

For those of you who are "p.o.'d" or think that there was a " paranoid 
... sick puppy" at work, I can tell you that the system manager in 
question is new to this role. A mistake was made by the individual,
which was recognized as such by line management, and a lesson has been
learned. I don't know how many of you were born with your knowledge 
and experience; I know I made a lot of mistakes to get mine. The 
policy is, as expected, that without 'due cause', a user's account 
will remain 'un-molested'. If a problem develops, an account remains 
'un-molested', will be DISUSER'd, and a discussion with the appropriate 
parties will commence. Case closed with regard to access and privacy 
issues.

I was pleased to see .68. Personally, I find the bombardment of 'tried 
by the media' situations, which seem to be increasing these days, 
rather tedious and time-wasting. The Digital I joined many years ago, 
was a place of 'openness' and 'reasonableness', not inclined to the 
emotional 'rangle' demonstrated by this exchange, which bears more 
resemblance to pea bouncing around in box. 

For those who thought system management had nothing to do, there 
certainly were enough replies generated, over a short period of time, 
to lead me to ask the question, what were the responders doing. It's 
not a Notes file I have time to read even on a monthly basis. (It was 
brought to my attention by a third person who happened to think I 
might be interested in the exchange.)

Now regarding the issue of process names ...

I am familiar with the informal policy of the group which discourages
the practice of users changing their process names. Certain abuses, in
the past, of very inappropriate names have caused criticism from
management. These cases do get dealt with on an individual basis, but
generally started with a 'different' but interesting process name,
then a 'cutesy' name and degenerated from there. The temptation for
other users to copy this 'neat' practice has a 'snowball' effect
giving the system managers an additional load of having to 'police'
their users to ensure that inappropriate names do not reflect poorly
on the professional appearance of the systems. 

In a group which has half a dozen system managers, managing over 60 
systems, spread 3,000 miles across 5 time zones, with a user base of 
over 2,500 users and over 4,500 user accounts, and a user support 
hotline which generates between 2,500 and 3,000 calls per month, I can 
understand their desire to make things run as smoothly as possible!

True, the process name as practically NIL effect on the VMS system. 
However, it has the same effect on the ability of a user to accomplish 
his/her tasks. We accept the restrictions on how we can decorate our
desks and office areas, yet respond with 'who the h*&^% are you system
manager' when they request restraint on how we 'decorate' our accounts.
I don't have a problem with it; but I believe that some people have 
lost sight of the fact the our business systems are not there for 
their personal entertainment but the successful support of our 
business.

I support our system managers, in a job that sees many long hours, 
interruptions by the minute, criticisms and problems at every corner 
and NIL thank you's. 

To keep me reminded of some lessons well learned, I have a poster 
(with a suitable picture) which says "Engage Brain before Opening 
Mouth". It's a worth while reminder that I think might restore some 
rationality to some of the notes dialogs I have seen and make Notes 
the productive and effective tool that it is.

	Regards
		Randy
        

re .82

>   The temptation for other users to copy this 'neat' practice
>   has a 'snowball' effect...
    
    Actually it had the opposite effect. True there were about 4 or
    5 users that changed their process name but it was of little
    consequence. Nothing worth noting (no PUN intended). After the
    hassling started with the reasons given in a previous note then
    more people jumped on the band wagon and started changing their
    process names.
    
>   We accept the restrictions on how we can decorate our desks
>   and office areas, yet respond with 'who the h*&^% are you system
>   manager' when they request restraint on how we 'decorate' our accounts.
    
    If the manager is this new it might explain his reasons not to do
    this. But he still could ask someone. If it's restraint for the
    sake of flexing muscles and standing on a soap box and yelling "It's
    my system, we own it and you only do what we tell you" then that's
    not restraint. That has more misdirected emotion than some of the
    replies in this note. The "who the hell are you" stands in relation to
    a system manager, or any one else for that matter, that accesses a
    users files without permission. This system and any other mail systems
    here are dominated by sales people, secretaries and managers that are
    somewhat or completely DCL illiterate. So it's just mostly the software
    types doing this and we're not known for offensive behaviour. Strange
    yes.. offensive no. Now sales on the other hand... just kidding. Some
    of the engineering systems are a gas to look at though.
    I don't advocate spending time looking at process names on other
    nodes but if you just happen to see some, at least it puts
    a smile on your face and then you carry on with what you were doing.
    We are still a fun company?? Aren't we??

    This incident it just a start though. Another incident on this system
    involves a priviledged user going though someones account and running
    executables and examining files. He then send mail to the victums
    manager stating that he was in this account and didn't like this
    and this, etc and also asking what was the purpose of these other
    things. That incident will probably be addressed through an impact
    report.

    Considering I have yet to see anything that looks like it could
    offend anybody, I think the person(s) should stop wasting their time
    and everyone elses and drop this.

    FLAME ON.... HOT, HOT
    
    If not then the managers should stop VMS from changing my process
    name to _LTAxxxx:. I find that offensive.

    FLAME OFF.
    
    All mail that I have received has come from SYSTEM or OPERATIONS.
    No one wants to put their name to anything. No wonder everyone looks
    at MIS as BIG BROTHER and that root canals are more fun. The only ones
    that work there are SYSTEM and OPERATIONS. The managers should try
    talking to field people (their customers) directly. Something wonderful
    might happen. We might all find out that there is a human being
    on the other end and that he/she needs to be understood, not just
    dictated to or feared.
    
    dmm aka "VMS realtime" previously "RSX oldtimer"
    

        I think a couple of important points are being made here.
        
        One is that if there are going to be policies, they need to be
        communicated BEFORE they are applied in specific instances, not
        after.  (And it's not enough to say "we told all the users six
        months ago" to someone who is new to the system -- policies must
        be communicated to new users when they start to use the system.)
        This may require that the policies get written down (heaven
        forbid) and handed, in writing, to the users. 
        
        Another is that when someone must be "disciplined" for violating a
        policy, it *must* be done carefully.  For instance, instead of
        just blowing away someone's process because the process name is
        "offensive" or "not in keeping with policy", the person should be
        contacted, e.g., on the telephone, or via MAIL, and *asked*
        whether they are aware that the process name is not what's
        considered acceptable, and reminded of the policy. 
        
        And, of course, the policy has to be reasonable, and it has to be
        applied consistently and fairly.  Policies that are believed to be
        arbitrary, or are perceived to be applied arbitrarily, tend to
        lead to disgruntled employees. 
        
        In other words, there may be some people management problems here
        that are disquised as system management problems. 
        
        Tom

    I think the fact that the "manager" was new puts a different slant
    on things - somewhat.
    
    At the risk of opening myself to criticism, it is one of my pet
    peeves that individuals are rarely sufficiently trained or experienced
    for the positions they must occupy.  

    I started my career at DEC doing VMS installs BEFORE I ever had an
    account on a VAX (old RSX-hack myself).  I agree, it was a painful
    experience when my inadequacies became highlighted.  But I'm sure
    it was equally painful for my customers that had the impression
    that DEC (in my persona) didn't know what it was doing.
    
    I won't belabor the issue, because I don't know the person or the
    details.  But at the very least, the situation is not one that should
    have been allowed to happen.  It should have been prevented either
    through the use of published policies, training, or some of the
    good old time DEC communication that was alluded to in .82.
    
    I think it is natural for readers in a conference like this to assume
    that the system manager held the position for a reason, knew what
    they were doing, and given those points, was doing something VERY
    wrong.
    
    Speaking as one the ASS-U-MEd, I know that no malice was intended
    to an inexperienced individual - but certainly toward ANYONE that
    willing abuses their position to demonstrate their control over
    others.
    
    Jim
    

    The person has been around a couple of years. So either he hasn't been
    told about not going into desks or accounts or maybe its general policy
    that they get to wander where they like and do what they like just
    because they have priviledges??
    
    I don't think its the latter. Innocent until caught with hands in
    the cookie jar.
    
    dmm
    

    
    	I would be interested in seeing the WORST of these offending
    	process name strings.  Perhaps it would not be appropriate
    	to post it in this conference, but I would be willing to see
    	it via MAIL.  (Nobody but me reads my mail...).  Just so I can
    	make my own judgements...
    
    	I have been involved with similar "personality differences" where 
    	a user and a system manager don't see things eye to eye.  
    	Stubbornness prevails on both sides.  The user usually feels 
    	the most abused because the sys manager has the power (system 
    	privs, etc.). 
    
    	I have been on systems DICTATED by system managers driven by
    	their own sense of self importance.  I have resented their
    	power, and what I perceived as their abuse of that power.
    	On the other side of the coin I can look back at those days
    	and all I can think of is the saying:  "The squeaky wheel gets
    	the most grease".
    
    	Altering files like LOGIN.COM for the sole purpose of enforcing
    	ones policies is not right.  Poking around in a users account
    	to find games, non-work-related files (letters, Christmas
    	cards, etc.), offensive material (I have an accumulation of
    	daily BJOD's), and whatever else, is also wrong.  It is an abuse
    	of privileges with which a privileged user entrusted.
    
    	However I would not be upset if the user were repeatedly warned
    	in person that a particular process name was unacceptable,
    	or if he were caught playing gamed DURING WORKING HOURS, or
    	if he had hacker command files that sent annoying messages to 
    	other users, and it was proven that someone from his system
    	was abusing such files.  I can see a system manager hunting
    	them down on his system -- especially if he sent out a fair
    	warning about the use or possession of such files.

    	I have grown and learned from my experiences.  One of the greatest
	things I learned was to try to see the situation from the other
    	guy's perspective.  Stubbornness begets stubbornness.  Anger
    	clouds your thinking.  Hatred causes unhealable scars.  All
    	for what?  Your pride?  Your rights?  Your dignity?  Your place
    	in the pecking order?  Lighten up.  Hopefully for all concerned
    	the situation is still salvageable if both sides would give
   	a little.  Couldn't process name strings be allowed if within
	reason?  I have never been on a system where I couldn't play
    	with my process name if I wanted to.  Perhaps some disinterested
    	manager could be a final judge for marginally-offensive names.
    	Why do you HAVE to change your process name at all?  So what
    	if your process name is _RTA1: (which, by the way is what mine
    	is right now...)  It was suggested that if other users don't
    	like your own process name they do not have to look at it.
    	Why do you have to look at you system-assigned one?  Perhaps
    	because just seeing it reminds you of the resentment of the
    	dictatorial way your system manager runs the system you happen
    	to be on.
    
    	This situation reminds me of my kids fighting.
    
    	Joe Oppelt