Re[2]: How do I get invisible character input?

} } In article <iw@byu.edu> ecktons@sirius.byu.edu (Sean Eckton) writes: } >> Your problem is in having the users share the same login. This is a very } >> bad idea; if you stick with it then I suspect that your problems have } >> just begun. Would you care to elucidate the reasons for this decision? } .. } >Ok, I'll explain. I am writing a system to allow representatives of all the } >departments here on campus to register hosts for nameservice. What they will } >do is telnet to the host, login with a standard user name and password which } >all of the representatives will have, then be able to add information about } >computers on campus. Each representative has a range of IP numbers assigned } >to him that he/she can assign at will. I want to descriminate between users } >at the informix level, not the unix level. I can do this, but I need a way } >for them to login using informix under the same unix account. If I added } >accounts for each representative, our account list would increase by 80+. } >They won't be using it often enough to warrant that many accounts. Some may } >use it once a month or less. Does this clear it up? Why do you say I will } >have problems? I am open for any suggestions. } } Hmm, it -may- be ok to share unix logins like this in this case. The sort } of thing I was more concerned about is when an admin says "oh, lets have all } of our payroll clerks use the same logname to make things easier..." } } I still have misgivings about the idea though. Wouldn't it be easier to } just add those 80 accounts than to jump through hoops building password } authentication into your application? There really is little overhead } in adding that number of accounts. } } Remember, the password mechanism is Unix's only real defense against attack. } A well-known logname/password is a security risk no matter how bullet proof } you think the application might be. Also, "who" works if they have unique } lognames. Just my 2c. } } -- } Hugh Grierson Fujitsu/ICL New Zealand - Software Development Centre } hugh@nezsdc.icl.co.nz Speaking for myself only. See figure 1. } ******************************************************************************* } Hugh/Sean, } } Something I tried with success some time ago--- I had a SINGLE database which } was used by a GROUP of 5 people or so. INFORMIX seemed to LOCK out another user } if one was currently using the database. } } My solution-- I had all in the GROUP chmod to 777 on their DIRECTORIES and } went in to each and created a SUBDIRECTORY just for that DATABASE. I then } established a LINK (ln command) with my DATABASE to the SUBDIRECTORY of the } other users. Also did a chgrp so all users were the same. } } Then their directories were RESET back to 700. Each member of the GROUP still } had WRITE ability to UPDATE the database even though INDIVIDUAL directories } were CUT OFF. } } This worked and their was NO CORRUPTION of data. } Why not put a .rhosts file out there for each of the people logging in? That way the account is still protected to some degree by the protection of the admin's account whereever (s)he is. It still ain't great. cheers j. _____________________________________________________________________________ Jack Parker | Hewlett Packard, BSMC Boise, Idaho, USA| Your .sig has expired, please enter jparker@hpbs2561.boi.hp.com | a new one. (208) 396-5388 (W) (208) 384-1623 (H) | _____________________________________________________________________________ Any opinions expressed herein are my own and not those of my employers. _____________________________________________________________________________