[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

236.0. "Network password problem" by MDVAX3::VEALEK (Moderator) Thu Apr 24 1986 16:24

Have a small question for you hackers out there.

Why is it that when you have as your password to a system the word
"password" that a network copy to an your account with that password 
bombs out with an "INVALID NODENAME ...." error message?

	IE:  COPY FOO.TXT BOOBOO"SMITH PASSWORD"::DUA0:[SMITH]*.*
                                          ^
					  |
					  +-- This is not working.

Try changing your password to "password" and try this.

Any comments/ideas would be appreciated.


Ken V.
T.RTitleUserPersonal
Name
DateLines
236.1ULTRA::PRIBORSKYTony PriborskyThu Apr 24 1986 16:428
    This is not a new discovery.   It has to do with the mechanism that
    VMS uses to echo a filename when remote access is specified.   It
    changes your password to the string "password", and places it into
    the Resultant filename buffer.  Later, when the resultant string
    is passed back again (in a wildcard stream), the presence of "password"
    is used to trigger the replacement of the original password.   Since
    there is no "original password"...   Well, you get the idea.  (Or
    something like that...   Will the real expert stand forward...)
236.2Re: 0 Serves you rigth for choosing an obvious passwordBISTRO::HEINHein van den Heuvel, Valbonne.Fri Apr 25 1986 07:420
236.3It replaces it Most of the time...SUBSYS::LAWLERMon Apr 28 1986 16:3211
    actually if you do a 
    $SET DEF NODE"user xxxxxx"::duax:[dirname]
    
    each subsequent operation like a $TYPE replaces the xxxxx with
    the string password, but doing a $SHO DEF returns the string
    with the origional password naked for all to see...
    
    				or at least v3.x did...
    
    					al
    
236.4IT is two different thingsTHEBAY::MTHOMASopen mouth, stick foot in mouth, ...Mon Apr 28 1986 17:115
    The $ TYPE is done by RMS (which unserstands the node"user xxx"::),
    the $ SHOW DEF is done by DCL blindly translating the logical SYS$DISK.  
    Anyways setting defualt to a remote node isn't supported.

    matt
236.5?!BACH::VANROGGENMon Apr 28 1986 23:4811
    I suppose I should ask this on another conference, but since .4
    brings it up:
    
    Any reason one can't set one's default directory to a remote node?
    And why logicals are translated by both RMS and DECNET? It seems
    DEC -doesn't- have it now, as far as network file access is
    concerned.
    
    			---Walter
    			(a frustrated VMS [& Unix & TOPS-20] user)
    
236.6PASTIS::MONAHANTue Apr 29 1986 06:4521
    	Logicals are not translated by DECnet (at least not the bit
    of DECnet involved in this discussion).
    
    	Setting one's default directory to a remote node is not supported
    because a very few things will not work correctly, and the things
    that will not work are not too easy to document. Basically, what
    does not work is those things that do not use RMS for their I/O,
    since it is RMS that has the code to transparently get at a remote
    file. A particular example where RMS is not used for disk I/O is
    paging. However, some activities that involve paging will work,
    since the image activator has some smarts too, and will copy a remote
    image file into the local disk page file and do all the fixups when
    a remote image is run. On the other hand, a read/write global section
    could never work, since it relies on every process that might be
    able to access it to use the same global page table in system space.
    Similarly, if your default device is local you can mount it if it
    is dismounted, but current DECnet protocols do not support a remote
    mount request.
    
    	Note that in many cases the problem is not with the "remote
    file access". That generally works fine.
236.7blue-skyingCLT::GILBERTJuggler of NoterdomSun May 04 1986 07:1019
    The problem noted in .0 ONLY occurs if "password" in the access
    control string is in lower-case (unless RMS password 'caching'
    is involved).

Getting way, way ahead of everything...

    Were "SET HOST remote-directory" to be supported, with stated
    restrictions, and password security were an issue, it would be
    tempting to just have the "SET DEFAULT" hide the password (where
    RMS and others could find it I suppose).  However, this easy but
    limited approach would preclude secure use of access-strings in
    logical names (so that a copy from one remote account to another
    would be handled easily).

    Logical names that are 'hidden' (except to privileged subsystems)
    may have other applications/may be a solution to other problems,
    such as (?) encryption key services.

    Actually, with ACLs on logical name tables, this may be feasible now.