This was meantioned a few times in Citrix's online forums - Citrix lamely claiming it was nessisary for functional reasons. This is particular problem has been fixed with the new Unix versions (v3.0.XX). Each user now gets an ~/.ICAClient directory for their personal settings. It's still has problems though. For some reason known best to themselves Citrix have decided to still make $ICAROOT/cache (usually /usr/lib/ICAClient) and /etc/icalicense/ mode 777. I suspect the licence files only come into play using Metaframe for Terminals but it's hard to reconcile the logic of a shared central location for all users. The cache directory is configurable within the client and isn't even turned on by default so why this directory needs to exist at all escapes me. Like you say - distressing that they would do this. More so that they would still get it wrong the second time around. M. On Fri, 28 May 1999, David Terrell wrote: > [ presumably this holds true for the other unix clients as well, but > all I have is linux to test on ] > > The Citrix Winframe linux client (used for accessing Winframe and > Windows NT Server Terminal Edition) has a simple configuration section. > Perhaps too simple.... All configuration information is stored in a > directory /usr/lib/ICAClient/config which is mode 777. This in and > of itself is bad news, since any user on the system can overwrite > configuration data. > > The situation is actually much worse than that. > > When you start up the actual session manager (wfcmgr) you get a listbox > of configured sessions. The data for this listbox is stored in the mode > 777 file /usr/lib/ICAClient/config/appsrv.ini. So there's a single > config file shared between all users. A sample session profile follows: > > [WFClient] > Version=1 > > [ApplicationServers] > broken= > > [broken] > WinStationDriver=ICA 3.0 > TransportDriver=TCP/IP > DesiredColor=2 > Password=0006f6c601930785 > Domain=NTDOM > Username=user > Address=hostname > > Yep. Passwords are stored in some kind of hash. What that hash is doesn't > really matter since you can just bring up wfcmgr and log in as that user. > > Terrible. > > I tried mailing both supportat_private and securityat_private but > neither of these addresses exist. > > > Workaround? wfcmgr supports the -icaroot parameter, but you basically > need to copy all the files in for it to work. So duplicate the tree in > your home directory, fix permissions, and do wfcmgr -icaroot $HOME/.ica. > > Alternatively, don't use it. > > Distressing that the company that was "bringing multiuser concurrent logons > to Windows NT" makes such a little effort at understanding multiuser > security.... [further editorialization left to the reader] > > -- > David Terrell > dbtat_private, dbtat_private I may or may not be speaking for Nebcorp, > http://wwn.nebcorp.com/~dbt/ but Nebcorp has spoken for you. >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:47:53 PDT