chin@fornax.UUCP (Hong Wai Chin) (12/06/90)
HI, I need a program which will perform similary to NET NAME USERID * command but not giving user for a "Abort, Ignore, Retry" option if the user put in the wrong passwd. I need the password security in order to exclude people from using some resources( e.g. files, printers etc. ) ANy help will be appreciated. fred chin@fornax.UUCP
TOMIII@MTUS5.BITNET (Thomas Dwyer III) (12/08/90)
In article <1741@fornax.UUCP>, chin@fornax.UUCP (Hong Wai Chin) says: > >HI, I need a program which will perform similary to NET NAME USERID * >command but not giving user for a "Abort, Ignore, Retry" option if >the user put in the wrong passwd. I need the password security in order >to exclude people from using some resources( e.g. files, printers etc. ) >ANy help will be appreciated. > >fred chin@fornax.UUCP Good luck. I've been trying to do this for months. It is possible to change your uid/gid with a simple program, but I know of no simple way to authenticate a password. In this respect, I find the toolkit very lacking. Thomas Dwyer III Email: tomiii@mtu.edu Network Programmer tomiii@mtus5.BITNET Computing Technology Services Voice: (906) 487-2110 Michigan Technological University Fax: (906) 487-2787
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (12/11/90)
Quoth TOMIII@MTUS5.BITNET (Thomas Dwyer III) (in <90342.015839TOMIII@MTUS5.BITNET>): #In article <1741@fornax.UUCP>, chin@fornax.UUCP (Hong Wai Chin) says: #> #>HI, I need a program which will perform similary to NET NAME USERID * #>command but not giving user for a "Abort, Ignore, Retry" option if #>the user put in the wrong passwd. I need the password security in order #>to exclude people from using some resources( e.g. files, printers etc. ) #>ANy help will be appreciated. #> #>fred chin@fornax.UUCP [I tried to reply to Fred, but email bounced.] What behaviour DO you want to see if the authentication fails? Or are you saying you want a Toolkit routine to authenticate a username/password and another one to set the uid/gid? #Good luck. I've been trying to do this for months. It is possible to #change your uid/gid with a simple program, but I know of no simple way #to authenticate a password. In this respect, I find the toolkit very #lacking. I guess I can't win. Half the folks are demanding that I tighten up security, the others want me to provide hooks to let you plug in an arbitrary uid/gid. However, I'm surprised at what you say. If you indeed know how to plug your uid/gid into the PCNFS.SYS data structures, you've solved the hard part. The rest is no more than a "callrpc()" away. After all, you have the server side: how hard is it to write the client? I confess: I was asked not to include the pcnfsd.x RPCGEN source in the PCNFSD.C file (that damned idea of "security through obscurity"), but it's published for all the world to see in the X/Open PC Interworking (PC)NFS spec. -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- *** For the 22nd month in a row, the British Chancellor of the Exchequer *** *** (then John Major, now PM) has announced that "inflation has peaked *** *** and will now begin to fall." And he managed to keep a straight face... ***
TOMIII@MTUS5.BITNET (Thomas Dwyer III) (12/13/90)
In article <3589@jaytee.East.Sun.COM>, geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) says: >[I tried to reply to Fred, but email bounced.] What behaviour >DO you want to see if the authentication fails? Or are you saying >you want a Toolkit routine to authenticate a username/password >and another one to set the uid/gid? > >#Good luck. I've been trying to do this for months. It is possible to >#change your uid/gid with a simple program, but I know of no simple way >#to authenticate a password. In this respect, I find the toolkit very >#lacking. I must admit that I was not too clear on my last posting. My complaint on the toolkit is for its lack of ability to perform the various "NET" functions such as logging in, mounting drives, etc. Granted, the toolkit is a major strength for PC-NFS. I would like however, not to be tied down to spawning NET.EXE for any network functions. This is a slow process and requires more memory than some DOS shells (ie - shell to DOS from an application) will let you have. >I guess I can't win. Half the folks are demanding that I tighten >up security, the others want me to provide hooks to let you plug in >an arbitrary uid/gid. However, I'm surprised at what you say. >If you indeed know how to plug your uid/gid into the PCNFS.SYS >data structures, you've solved the hard part. The rest is no more >than a "callrpc()" away. Yes, I do know how to plug a new uid/gid into PCNFS.SYS's structures, and yes that is the hard part, however I cannot expect Sun to leave these structures in the same spot in future releases, patches, etc. Thomas Dwyer III Email: tomiii@mtu.edu Network Programmer tomiii@mtus5.BITNET Computing Technology Services Voice: (906) 487-2110 Michigan Technological University Fax: (906) 487-2787
G.Eustace@massey.ac.nz (Glen Eustace) (12/13/90)
I second Geoff's statements re: password authentication. We have been using a home grown daemon to do exactly that ( It returned a lot of other information as well ). I have recently changed over to using an RPC call to check with pcnfsd before spawning the NET NAME. As part of the above excercise I seem to have struck what appears to be a buggy part of the toolkit. I originally wanted to do the following, clntudp_create() clnt_call()...clnt_call()...clnt_call()...clnt_call()... clnt_destroy() the first clnt_call almost always fails with error 3. callrpc()....callrpc()....callrpc()....callrpc().... however works. In a trivial program, the prior example usually works, it is only in the larger program that things really come unstuck. In trying to trace what is happening, it looks like somewhere in udp_open(), areas of the programs data are arbitrarily overwritten. I would guess that in the trivial case nothing of importance is being overwritten. As an aside, both the trivial case and it's larger cousin work fine when compiled on the unix host. Anyone any ideas? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen Eustace, Software Manager, Computer Centre, Massey University, Palmerston North, New Zealand. EMail: G.Eustace@massey.ac.nz Phone: +64 63 69099 x7440, Fax: +64 63 505 607, Timezone: GMT-12
dwight@ibmpcug.co.uk (Dwight Ernest) (12/16/90)
In article <90342.015839TOMIII@MTUS5.BITNET> TOMIII@MTUS5.BITNET (Thomas Dwyer III) writes: > In article <1741@fornax.UUCP>, chin@fornax.UUCP (Hong Wai Chin) says: > >HI, I need a program which will perform similary to NET NAME USERID * > >command but not giving user for a "Abort, Ignore, Retry" option if > Good luck. I've been trying to do this for months. It is possible to I've succeeded in doing this using a combination of things in a batch file, including an ANSI.SYS (or NANSI.SYS)-based "invisible" escape sequence. If anyone wants to see how, drop me a line and I'll make up a small archive and mail it out to those who are interested. --Dwight -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group. -- --Dwight Ernest (reply to dwight%independent.uucp@ukc.ac.uk)
ccc_jc@waikato.ac.nz (12/20/90)
>In article <3589@jaytee.East.Sun.COM>, geoff@hinode.East.Sun.COM (Geoff Arnold @ >Sun BOS - R.H. coast near the top) says: >>[I tried to reply to Fred, but email bounced.] What behaviour >>DO you want to see if the authentication fails? Or are you saying >>you want a Toolkit routine to authenticate a username/password >>and another one to set the uid/gid? >> >>#Good luck. I've been trying to do this for months. It is possible to >>#change your uid/gid with a simple program, but I know of no simple way >>#to authenticate a password. In this respect, I find the toolkit very >>#lacking. >I must admit that I was not too clear on my last posting. My complaint >on the toolkit is for its lack of ability to perform the various "NET" >functions such as logging in, mounting drives, etc. Granted, the toolkit >is a major strength for PC-NFS. I would like however, not to be tied >down to spawning NET.EXE for any network functions. This is a slow >process and requires more memory than some DOS shells (ie - shell to DOS >from an application) will let you have. Just to add my voice to the above sentiment..We are using the same procedure, use the toolkit to authenicate then spawn to net.exe to get the login or mount etc. Very slow and tedious. Some routines to link into my own programs to perform net name, net use are what i would put on top of my wish list John Creek University of Waikato