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

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

894.0. "Drawer access to *Local" by BERN01::MAURERF (Isn't your mouse looking for cheese?) Thu Jun 18 1992 15:34

    I tried to create a drawer with access to *Local and expected that all
    local users could access this drawer. In fact this was not the case
    because no ALL-IN-1 users had the Local identifier granted.
    
    My question is, is it suposed to be done by hand or is there something
    wrong on my system?
    
    Felix
T.RTitleUserPersonal
Name
DateLines
894.1IOSG::MAURICECeci n'est pas une noteThu Jun 18 1992 15:5410
    VMS is a bit cagey about whether users get the LOCAL identifier. I have
    a workstation and I usually SET HOST to IOSG rather using the LAT. When
    I do a $show proc/priv I am told I have a REMOTE Process right. Were I
    to use the LAT then I would have LOCAL. 
    
    Does this explain your problem?
    
    Cheers
    
    Stuart
894.2Another issue around *LOCAL FYIIOSG::STANDAGEOink...Oink...MoooooooooooooooooooooooooooooooooThu Jun 18 1992 19:2323
    
    All,
    
    Actually, there is a problem with *LOCAL which I only just discovered
    today.
    
    If a drawer is shared with *LOCAL and only CREATE privilege is granted
    then it doesn't work as expected. The FCS returns insufficient
    privilege when a user attempts to create in that drawer.
    
    Similarly, EDIT privilege has the problem associated with it when
    *LOCAl is used.
    
    There are no problems however when READ, DELETE/REFILE or CONTROL 
    privileges are granted.
    
    Note: This is isolated to *LOCAL, specifying usernames works just fine.
    
    
    
    Kevin.
    
    
894.3LAT equal LOCALBERN01::MAURERFIsn't your mouse looking for cheese?Fri Jun 19 1992 15:258
    Stuart,
    
    You are right, I was logged in via set host. If *local identifier is
    used, then it's better to connect via LAT.
    
    Thanks for your help.
    
    Felix
894.4The reasonSCOTTC::MARSHALLPearl-white, but slightly shop-soiledFri Jun 19 1992 17:308
The reason why you don't get *LOCAL with SET HOST...

*LOCAL implies you are local (physically) to the system.  But if you SET HOST,
you could be on the other side of the world.  That's why LAT (LOCAL area
transport) connections get *LOCAL, but SET HOST (and other types of connection,
I expect) get *WORLD instead.

Scott
894.5Solution ? BERN02::MUELLERSMon Mar 08 1993 17:0226
    
    
    
    
    
    Hi,
    
    what's the solution for the problem described in .2? 
    
>   Actually, there is a problem with *LOCAL which I only just discovered
>   today.
>    
>   If a drawer is shared with *LOCAL and only CREATE privilege is granted
>   then it doesn't work as expected. The FCS returns insufficient
>    privilege when a user attempts to create in that drawer.
>    
>   Similarly, EDIT privilege has the problem associated with it when
>   *LOCAl is used.
    
    
    I shared a drawer with *LOCAL and granted Y Y Y Y _ . A non-privileged
    account cannot create or edit documents in this folder. 
    
    
    	Stefan
    
894.6You're seeing the same as me!IOSG::STANDAGEOink...Oink...MoooooooooooooooooooooooooooooooooMon Mar 08 1993 17:2016
    
    Stefan,
    
    
    >>I shared a drawer with *LOCAL and granted Y Y Y Y _ . A non-privileged
    >>account cannot create or edit documents in this folder.
    
    Yes, that's exactly what I reported. At the moment, there does not seem
    to be a workaround, other than to share the drawer with spcific users
    and/or groups.
    
    
    Kevin.
    
    
    
894.7FCS does not understand *LOCALCHRLIE::HUSTONMon Mar 08 1993 18:0012
    
    
    It appears as though the way *LOCAL works is to check for a VMS
    rights ID that VMS gives you when you are a local loging. note that
    this rights ID is not in teh rightslist for teh users. THe FCS
    only knows about the ones in teh rightslist.dat for that user.
    
    There is no workaround, except as Kevin says in .6, share with 
    specific users.
    
    --Bob
    
894.8Fixed? When?BERN02::MUELLERSTue Mar 09 1993 07:476
    Kevin, Bob,
    
    Thanks for your quick answers. Could somebody tell us whether this
    problem will be fixed in the next release? Thanks!
    
    Stefan
894.9??IOSG::STANDAGEOink...Oink...MoooooooooooooooooooooooooooooooooTue Mar 09 1993 08:5613
    
    Stefan,
    
    >>Thanks for your quick answers. Could somebody tell us whether this
    >>problem will be fixed in the next release? Thanks!
    
    I'm afraid we can't talk about futures in this conference, but the
    problem is on our bug list and will be considered for a future release.
    
    
    Kevin.
    
    
894.10*WORLDANGLIN::HARRISABicycles need seat beltsTue Aug 24 1993 22:395
    Read about *WORLD in a manual.
    
    Will this work to alleviate the problems with *LOCAL ?
    
    Ann