On Sun, Mar 10, 2002 at 01:22:19PM -0800, Daniel A. Koepke wrote: >On Sun, 10 Mar 2002, Mike Stilson wrote: > >> Hideously unsafe, actually. > >Why? Which of your coders would you not want to have access to the SQL >database? Why did you give them shell access if you didn't trust them? Because what would happen if thru a miracle of cut-n-paste in an email while, or making a diff to post, or anything else you grab some more of your code than intended. What if *buf decided to go wandering off through memory sometime and act() spits that out to a player? Your point's perfectly valid, but to me, hard-coding a cleartext password in something is a mistake in the first place, let alone in a program that you might make publicly available portions of. > >> Why not just do something simple like this? > >How does this stop anyone that has access to your code from getting the >password? If they have been granted read-write access to the code, a >simple syllogism illustrates that they still have access to your sql_cnf >file regardless of file permissions: > > The Mud can read the sql_cnf file to get its configuration. > User A has read-write access to the Mud's code. > Therefore, User A can read the sql_cnf file. Assuming anyone can run the mud in the first place. If only mudadmin can run it, then that's the only account to worry about, and that's only needed to be known by a couple people. Individual coders can either be given their own database with their own access to test, or even a common one for all testing to take place in. > >He need only add a single line of code to the bottom of the load_sql() >function to log() the DB, user, password, et al. The Mud is setuid to >have the permissions to read the file, but he can read the logged output >when he runs the Mud. Game over. Hopefully you notice these things in their code before you use their changes. "grep passwd coder.diff" would show it for example. I guess, though, this all really applies to a development model where there is a final "end of the line" person/people who are entrusted to maintain and run the actual version put open to the public. >If they only have read access to the code, you've clearly mismanaged your >file permissions. You've given someone access to something they don't >need access to. In that case, introducing more permissions to (mis)manage >is probably not the best solution. That's always the unavoidable problem, if you can't actually set your perms right then no amount of security in anything is going to matter. [ snip about trusting & weak links ] This is a problem for the whole system in general, not just the mud. If you're handing out shell accounts to anyone & everyone, you might as well just save the time and type passwd -d root. Still I see hardcoded passwords as weakening your security, however little or much you consider it. > >All of that said, the separate configuration file is probably still worth >doing for (no other reason than) flexibility. It's nice to be able to >change things without having to recompile and having different executables >for different configurations. I see a few reasons. 1: so I don't hard-code passwords. 2: flexibility. 3: add a new option "-t" perhaps, so it would use a set of "test" tables rather than the ones from the actual running mud. -me -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | | Newbie List: http://groups.yahoo.com/group/circle-newbies/ | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT