dent@unocss.UUCP (Dave Caplinger) (06/15/89)
Can anyone suggest a way to set the "chooser" username once and then prevent it from being changed in the future? I'm building a public user room Apple- Share network (file/print served), but I want to be able to tell which Macs (by physical location, like "Mac 3" etc) are 1) Logged into the server (all of the public macs will be using the guest account), and/or 2) connected to AppleTalk (whether they yanked the plug or not :-). Is the function of "Responder" related to this, and if not, what does "Responder" do? Can this be acheived at all with any existing software? Making each Mac log into the server as a seperate user would not be a problem, but users can still (and they will, believe me) change the username to whatever they like. (Using the auto-login feature of AppleShare is my last resort, and I'd rather find another way if there is one...) Thanks for any help you may be able to provide... -/ Dave Caplinger /------------------+----------------------------------- Microcomputer Specialist | Internet: unocc07@zeus.unl.edu "Computing and Data Communications" | UUCP: uunet!btni!unocss!dent University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1 Omaha, NE 68182 | or dc3a+@andrew.cmu.edu
tim@hoptoad.uucp (Tim Maroney) (06/17/89)
In article <835@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes: >Can anyone suggest a way to set the "chooser" username once and then prevent >it from being changed in the future? No. Macs are not secure machines. Anyone would be able to defeat your scheme by booting from a floppy disk or throwing away the INIT file you use to implement this scheme. The only somewhat feasible possibility is to put special code in your hard disk boot blocks which enforces this, and then it would be very likely to break under future OS revisions. Macs are not secure and you'll have to plan around that fact. However, you can detect which Appletalk network a Macintosh is connected to simply by checking the network number of its address. Not what node it is on the network, but the network is no problem. This is also rather difficult to defeat because it is enforced by the gateways and bridges. Still, an after hours user would be able to remotely reconfigure some gateways and bridges without raising any immediate alarms; so you still can't absolutely rule out masquerading. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "I was brought up in the other service; but I knew from the first that the Devil was my natural master and captain and friend. I saw that he was in the right, and that the world cringed to his conqueror only from fear." - Shaw, "The Devil's Disciple"
keir@vms.macc.wisc.edu (Rick Keir, MACC) (06/17/89)
In article <835@unocss.UUCP>, dent@unocss.UUCP (Dave Caplinger) writes... >Can anyone suggest a way to set the "chooser" username once and then prevent >it from being changed in the future? I'm building a public user room Apple- >Share network (file/print served), but I want to be able to tell which Macs >(by physical location, like "Mac 3" etc) are 1) Logged into the server (all >of the public macs will be using the guest account), and/or 2) connected to >AppleTalk (whether they yanked the plug or not :-). > The username is stored as a string in the "System" file; I don't remember where. The chosen printer is stored in "STR " -8192. I suppose you could set these, then delete the chooser; however I strongly recommend not doing this. It is just too useful for users to look in the chooser and see if the printer is responding, and too many things can reset these values. You have to assume in a public setting that users will add their own DAs and screw up your files constantly. Therefore, the cleanest solution I know is to make yourself a modified chooser, install it, and hope it doesn't get replaced too often by a user with his/her own Font/DA mover. To modify: get ResEdit, and a copy of the chooser in the Font/DA mover "suitcase" file. Open this file with ResEdit, and edit the dialog box which contains the template for the chooser's main dialog. On my system (6.0.2) this is "DITL -16000" but your mileage may vary; it should look familiar when you see it. Expand the dialog box & put the edit text field for username out of the original rectangle; then close back to normal dimensions. Voila: all the items are present bu the user cannot edit the field. (My thanks to Chuck Hutchins, the Apple Education Coordinator here, for this idea).
tim@hoptoad.uucp (Tim Maroney) (06/17/89)
In article <835@unocss.UUCP>, dent@unocss.UUCP (Dave Caplinger) writes... >Can anyone suggest a way to set the "chooser" username once and then prevent >it from being changed in the future? In article <1889@dogie.macc.wisc.edu> keir@vms.macc.wisc.edu (Rick Keir, MACC) writes: > Therefore, the cleanest solution I know is to make yourself >a modified chooser, install it, and hope it doesn't get replaced >too often by a user with his/her own Font/DA mover. To modify: >get ResEdit, and a copy of the chooser in the Font/DA mover >"suitcase" file. Open this file with ResEdit, and edit the >dialog box which contains the template for the chooser's main >dialog. On my system (6.0.2) this is "DITL -16000" but your >mileage may vary; it should look familiar when you see it. >Expand the dialog box & put the edit text field for username >out of the original rectangle; then close back to normal >dimensions. Voila: all the items are present bu the >user cannot edit the field. (My thanks to Chuck Hutchins, >the Apple Education Coordinator here, for this idea). No, this doesn't work, at least on System 6.0.3 (which I'm pretty sure has the same Chooser as 6.0.2). If you move the editText item out of the box, all that means is that the user can't see it. Keyboard events still go to the field. I just spent a few minutes trying this and I was able to change my user name with the editText field out of the dialog box; I just couldn't see that I'd changed it until I moved the field back into bounds. Try it yourself. So then I tried another approach -- changing the type of the field from editText to staticText. However, it appears that the Chooser does a SetDItem to change the field type back to editText. Once again, I was able to change my user name without difficulty -- the only difference was that the usual editText "bounding box" did not appear around the text item. If either of these approaches did work, they would provide only what I usually call "Level I Security" -- that is, prevention of casual abuse by inexperienced users. Neither one would even approach "Level II", which is protection against clever users deliberately trying to circumvent the mechanisms using non-programmer tools. In my opinion, Level I security is usually pointless, but these two approaches don't even provide Level I. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "Next prefers its X and T capitalized. We'd prefer our name in lights in Vegas." -- Louis Trager, San Francisco Examiner
steele@unc.cs.unc.edu (Oliver Steele) (06/17/89)
keir@vms.macc.wisc.edu (Rick Keir, MACC) writes: >In article <835@unocss.UUCP>, dent@unocss.UUCP (Dave Caplinger) writes... > >>Can anyone suggest a way to set the "chooser" username once and then prevent >>it from being changed in the future? [....] >> [....] > Therefore, the cleanest solution I know is to make yourself >a modified chooser, install it, and hope it doesn't get replaced >too often by a user with his/her own Font/DA mover. To modify: >get ResEdit, and a copy of the chooser in the Font/DA mover >"suitcase" file. Open this file with ResEdit, and edit the >dialog box which contains the template for the chooser's main >dialog. On my system (6.0.2) this is "DITL -16000" but your >mileage may vary; it should look familiar when you see it. >Expand the dialog box & put the edit text field for username >out of the original rectangle; then close back to normal >dimensions. Voila: all the items are present bu the >user cannot edit the field. (My thanks to Chuck Hutchins, >the Apple Education Coordinator here, for this idea). Almost. You can't see the edit field, but you can still type into it. Moreover, it's still selected when you call up the Chooser, so any characters you type go into it by default. On my system (Mac II; System 6.0.0; Chooser 3.3), changing the type of the dialog item from editable text to static text did the trick. It still shows up in the Chooser window (as white on black since SelIText works on static text too, at least on my machine), and the cursor still changes to an ibeam while it's over the text, but clicking and typing don't change the string in any way. You might want to test this behavior on all the models of Mac in your labs. It's an undocumentated feature that SelIText, which Chooser calls on that dialog item, does something reasonable on static text instead of, say, blowing up. --------------------------------------------------------------------------- Oliver Steele ...!decnet!mcnc!unc!steele UNC-CH Linguistics steele@cs.unc.edu
jmunkki@kampi.hut.fi (Juri Munkki) (06/18/89)
In <1889@dogie.macc.wisc.edu> keir@vms.macc.wisc.edu (Rick Keir, MACC) writes: >Can anyone suggest a way to set the "chooser" username once and then prevent >it from being changed in the future? I'm building a public user room Apple- >Share network (file/print served), but I want to be able to tell which Macs >(by physical location, like "Mac 3" etc) are 1) Logged into the server (all >of the public macs will be using the guest account), and/or 2) connected to >AppleTalk (whether they yanked the plug or not :-). In article <835@unocss.UUCP>, dent@unocss.UUCP (Dave Caplinger) replies: >The username is stored as a string in the "System" file; >I don't remember where. The chosen printer is stored in "STR " >-8192. How about setting the protected bit (with ResEdit) after setting the names? I don't know how the chooser would react to this, but it might work. _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
tim@hoptoad.uucp (Tim Maroney) (06/19/89)
In article <22951@santra.UUCP> jmunkki@kampi.hut.fi.hut.fi (Juri Munkki) writes: >How about setting the protected bit (with ResEdit) after setting the names? >I don't know how the chooser would react to this, but it might work. I tried it and got confusing results. First, I was able to change the name even with the 'STR ' resource's protected bit set. However, it appears that if you then go in and open the resource with ResEdit again, it reverts to the previous name. Open it once and it shows the new name; close it and open it again, and it shows the old name. This is very strange behavior and I can only speculate on the reasons. (I don't feel like stepping through the DA in MacsBug to make sure, frankly.) It would appear that when the Chooser attempts to modify the 'STR ' resource, it receives an error. This is what would be expected since the protected bit is set. However, it interprets this error as meaning "resource not present" regardless of where the error happens or what is the actual error code. It then does an AddResource to create a new copy of the 'STR ' with the new name, assuming that it has not yet been set. The Resource Manager is not sensitive to this error and will let you create two resources with the same ID. I believe this is what happens. However, at some point ResEdit is detecting this error and deleting the later copy of the resource without telling you. This is why it pops up with the new value the first time, but reverts to the old value the second time. This would imply that the checking happens when you close the window associated with a resource. (Perhaps Jon Singer could give some information on this?) So the answer is -- this does not appear to be safe, as setting the protected bit can cause the Chooser to introduce an error into the resource file. Furthermore, it does not work even if you consider the error acceptable; since the Resource Manager will return the most recently added copy of a duplicate resource, the newer (changed) version of the name will persist. You can verify this for yourself. Set the protected bit and close the system file; bring up the Chooser and change the name; close the Chooser; bring up Chooser again and see that the name has in fact been changed; repeat the last two steps two or three times just to make sure; give up and fix the resource file. I don't mean to revert to cranky mode again, but this is the second suggestion in the last couple of days that has been put forward without spending a few minutes doing rudimentary testing with ResEdit. This kind of thing does not improve the network's signal to noise ratio. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "Please help support the moratorium on meaningless quotes in .signatures." -- Doug Asherman on rec.music.cd
jmunkki@kampi.hut.fi (Juri Munkki) (06/19/89)
In <22951@santra.UUCP> jmunkki@kampi.hut.fi.hut.fi (Juri Munkki) writes: >How about setting the protected bit (with ResEdit) after setting the names? >I don't know how the chooser would react to this, but it might work. In article <7697@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >I tried it and got confusing results. First, I was able to change the >name even with the 'STR ' resource's protected bit set. However, it This is because the current handle in RAM is changed. This means that anyone who really wants to change the username can change it. I think this is a good feature, but someone might disagree. >appears that if you then go in and open the resource with ResEdit >again, it reverts to the previous name. Open it once and it shows the >new name; close it and open it again, and it shows the old name. This >is very strange behavior and I can only speculate on the reasons. (I >don't feel like stepping through the DA in MacsBug to make sure, >frankly.) ResEdit is a very strange program. I think the strange behavior was caused by ResEdit. The old version is the disk version (in the system file) and the new version is the RAM version. >It would appear that when the Chooser attempts to modify the 'STR ' >resource, it receives an error. IM-I doesn't say if this should create an error. In fact, there is no error for this situation. I took a look at the chooser code and it doesn't check for any errors. It probably should, because the system file might be locked in some other ways too. It just calls HNoPurge, ChangedResource, WriteResource and HPurge. >This is what would be expected since >the protected bit is set. However, it interprets this error as meaning >"resource not present" regardless of where the error happens or what is >the actual error code. It then does an AddResource to create a new >copy of the 'STR ' with the new name, assuming that it has not yet >been set. AddResource is never called when writing the resource. I think it is called when chooser is opening. The first time you open the chooser when the STR does not exist, it takes a lot longer than normally. >So the answer is -- this does not appear to be safe, as setting the >protected bit can cause the Chooser to introduce an error into the >resource file. The answer is -- you didn't bother to check it well enough yourself! I knew there would be a copy in RAM and the good thing is that the user thinks the name is changed when it's not actually written to disk. This is what would happen if the same thing was done with an INIT and I seem to remember that the original poster wanted an INIT. The choosername will revert to the original the next time the Mac is restarted. >Furthermore, it does not work even if you consider the >error acceptable; since the Resource Manager will return the most >recently added copy of a duplicate resource, the newer (changed) >version of the name will persist. You can verify this for yourself. >Set the protected bit and close the system file; bring up the Chooser >and change the name; close the Chooser; bring up Chooser again and see >that the name has in fact been changed; repeat the last two steps two >or three times just to make sure; give up and fix the resource file. I do not get multiple resources. I'm running chooser 3.3.1. >I don't mean to revert to cranky mode again, but this is the second >suggestion in the last couple of days that has been put forward without >spending a few minutes doing rudimentary testing with ResEdit. This >kind of thing does not improve the network's signal to noise ratio. I was sure that it would work and I read my Inside Macintosh before posting... _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
wade@sdacs.ucsd.EDU (Wade Blomgren) (06/20/89)
In article <1889@dogie.macc.wisc.edu>, keir@vms.macc.wisc.edu (Rick Keir, MACC) writes: > Open this file with ResEdit, and edit the > dialog box which contains the template for the chooser's main > dialog.... > .....it should look familiar when you see it. > Expand the dialog box & put the edit text field for username > out of the original rectangle; then close back to normal > dimensions. Voila: all the items are present bu the > user cannot edit the field. (My thanks to Chuck Hutchins, > the Apple Education Coordinator here, for this idea). An alternative might be to change the field type to 'static text' instead of 'editable text'. That way you can actually see the chooser name yourself if you need to check the machine to make sure it has not been changed, without having to run ResEdit... Wade Blomgren wade@sdacs.ucsd.edu
kempf@tci.UUCP (Cory Kempf) (06/20/89)
In article <1889@dogie.macc.wisc.edu> keir@vms.macc.wisc.edu (Rick Keir, MACC) writes: >In article <835@unocss.UUCP>, dent@unocss.UUCP (Dave Caplinger) writes... >>Can anyone suggest a way to set the "chooser" username once and then prevent >>it from being changed in the future? > Therefore, the cleanest solution I know is to make yourself >a modified chooser, install it, and hope it doesn't get replaced >too often by a user with his/her own Font/DA mover. To modify: [...] >Expand the dialog box & put the edit text field for username >out of the original rectangle; Alternatively, you could change the EditText Item to a Static Text Item. That way, the username would be displayed, but not changed (unless of course someone decided to bring in their own chooser, etc). +C -- Cory Kempf Technology Concepts 40 Tall Pine Dr. uucp: {anywhere}!uunet!tci!kempf, kempf@tci.uu.net Sudbury MA 01776 phone: (508) 443-7311 x341 DISCLAIMER: TCI is not responsible for my opinions, nor I for theirs
holland@m2.csc.ti.com (Fred Hollander) (06/21/89)
In article <7697@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >I don't mean to revert to cranky mode again, but this is the second >suggestion in the last couple of days that has been put forward without >spending a few minutes doing rudimentary testing with ResEdit. This >kind of thing does not improve the network's signal to noise ratio. I don't think we should be to critical of ideas presented in this forum. As long as they're presented as suggestions, not proven facts, even if they're flawed, they still stimulate intelligent and helpful discussions. Fred Hollander Computer Science Center Texas Instruments, Inc. hollander@ti.com The above statements are my own and not representative of Texas Instruments.
mjm@eleazar.dartmouth.edu (Michael McClemen) (06/21/89)
In article <835@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes: >Can anyone suggest a way to set the "chooser" username once and then prevent >it from being changed in the future? I'm building a public user room Apple- >Share network (file/print served), but I want to be able to tell which Macs >(by physical location, like "Mac 3" etc) are 1) Logged into the server (all >of the public macs will be using the guest account), and/or 2) connected to >AppleTalk (whether they yanked the plug or not :-). I'm not sure that locking the chooser name is the best way to do this. Anyone booting from a floppy disk (or hacking with resedit) could change it. However, for your purposes, what you need is simply an init that would set itself up as an Appletalk responder and broadcast a string stored on the machine's hard disk in response to a given signal. As to where you could find such a beastie, though, I've no idea... >Is the function of "Responder" related to this, and if not, what does >"Responder" do? Can this be acheived at all with any existing software? I'm not sure... >-/ Dave Caplinger /------------------+----------------------------------- > Microcomputer Specialist | Internet: unocc07@zeus.unl.edu > "Computing and Data Communications" | UUCP: uunet!btni!unocss!dent > University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1 > Omaha, NE 68182 | or dc3a+@andrew.cmu.edu Michael McClennen
tim@hoptoad.uucp (Tim Maroney) (06/21/89)
In <22951@santra.UUCP> jmunkki@kampi.hut.fi.hut.fi (Juri Munkki) writes: >How about setting the protected bit (with ResEdit) after setting the names? >I don't know how the chooser would react to this, but it might work. In article <7697@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >I tried it and got confusing results. First, I was able to change the >name even with the 'STR ' resource's protected bit set. In article <22959@santra.UUCP> jmunkki@kampi.hut.fi.hut.fi (Juri Munkki) writes: >This is because the current handle in RAM is changed. This means that >anyone who really wants to change the username can change it. I think >this is a good feature, but someone might disagree. First, thanks for the explanation. I hadn't realized that when dealing with a System file, the RAM copy would open first if there was one. Then of course closing the window does a ReleaseResource and the next fetch is from the disk. This approach could blow away some system software if it assumes that a non-purgeable resource that's been read in once will always be in RAM, but otherwise, it makes sense. Second, since you agree that this doesn't prevent the user from changing the Chooser name, what are we arguing about? And if the goal is preventing this change, how can you say this is a good feature? >>It would appear that when the Chooser attempts to modify the 'STR ' >>resource, it receives an error. > >IM-I doesn't say if this should create an error. In fact, there is no >error for this situation. I took a look at the chooser code and it >doesn't check for any errors. It probably should, because the system >file might be locked in some other ways too. It just calls HNoPurge, >ChangedResource, WriteResource and HPurge. (So in fact the Chooser name change lasts only until the System Heap becomes too full for a Memory Manager request and the 'STR ' is purged.) Thanks; like I said, I didn't feel like poking around in the DA code. I can't believe that the Resource Manager doesn't stick an error code in ResError when you try to write a protected resource, though! (Actually, having disassembled large parts of the Resource Manager, I can believe just about anything....) >AddResource is never called when writing the resource. I think it >is called when chooser is opening. The first time you open the >chooser when the STR does not exist, it takes a lot longer than >normally. That appears to be correct; the 'STR ' for the name is not present in the copy of the desk accessory in the "Desk Accessories" file on the Apple system disks. >I knew there would be a copy in RAM and the good thing is that the >user thinks the name is changed when it's not actually written to >disk. The good thing? In what way is a misleading feature that only partially does the job a good thing? The misleading part is especially bad. Just we we need is for the users of a Macintosh to be less certain that it will behave predictably and obviously, so they will rveert to the "I'm afraid to type 'help' because it might erase all my files" so common on other machines. If there is a good solution, it is one that doesn't confuse the user. >I was sure that it would work and I read my Inside Macintosh before posting... You knew that it *wouldn't* work and you went ahead and posted it without any warnings to that effect.... PS. Does anyone know how reserved DA ids are enforced by the Font/DA Mover? I assume that how it works is that any DA which is in the reserved range in the suitcase file will be copied with that ID, but suppose there is already a different DA there -- what happens? Just curious because the Chooser now sits on the space that the Puzzle used to take up, and I was wondering what would happen if you had an old Puzzle and installed the Chooser. I don't have an old Puzzle or I'd just check. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "Americans will buy anything, as long as it doesn't cross the thin line between cute and demonic." -- Ian Shoales
jmunkki@kampi.hut.fi (Juri Munkki) (06/21/89)
In article <7720@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: <In <22959@santra.UUCP> jmunkki@kampi.hut.fi.hut.fi (Juri Munkki) writes <>I knew there would be a copy in RAM and the good thing is that the <>user thinks the name is changed when it's not actually written to <>disk. < <The good thing? In what way is a misleading feature that only partially <does the job a good thing? < <The misleading part is especially bad. Just we we need is for the users <of a Macintosh to be less certain that it will behave predictably and <obviously, so they will rveert to the "I'm afraid to type 'help' because <it might erase all my files" so common on other machines. If there is a <good solution, it is one that doesn't confuse the user. The original posting wanted an INIT that would "fix" the choosername every time the Mac is restarted. Probably the best solution is to set the protected bit _and_ change the chooser edit text item into a static text item. _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
tim@hoptoad.uucp (Tim Maroney) (06/22/89)
In article <23016@santra.UUCP> jmunkki@kampi.hut.fi (Juri Munkki) writes: >Probably the best solution is to set >the protected bit _and_ change the chooser edit text item into a static >text item. Juri, I already dealt with that. The Chooser *makes* it an edit text item no matter what the dialog template says. I don't know whether that's through a SetDItem or if it's a side effect of calling SelIText on a static text item, but all it does is make things even more confusing for the user. There's a thing that looks like a static text box but responds to input like an edit text box. (Including setting the name as usual in the resource, or in RAM only if the resource is protected.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "The above opinions and suggestions have absolutely nothing to do with the little, fat man putting crisp, $100 bills in my pocket." -- Alan Vymetalik