> I agree to this, a maintainer-script shouldn't just write on random > places on the filesystem. > For instance, looking a bit better at the code, I think it has a serious > security problem. What if a malicious would do the following: > > touch mydata.gwb > ln -s /sbin/init mydata.update.gw
Hmmm, right. The code should at least check for an existing .gw file, do nothing but issue a warning if it exists (link or not). > Don't take it personally, I was just pissed some maintainer script was > writing to my precious backups... > > Maybe an alternative to removing the code entirely is to drop the > converted files in a dir under /var/backup and tell the admin it can > find updated files there. You should do some careful temporary file > creation there. Yes, this needs to be re-examined post-sarge. At this moment, I'm left with the problem and I think that I will take the safe path and just comment out the export functions, even the one which exports files in the common path. It is way too late for risky changes, so I think the safest solution is just disabling this whole part of the prerm scripts. If a structure change happens in the sarge->etch development phase, I will probably deal with the problem in the preinst phase (by issuing a debconf warning and allow users to stop the upgrade process so that they have an opportunity to first export their data files). Thanks for reporting...even if this first made me a little bit sick, I must admit..:-). You were certainly right and that part of the maintainers scripts is indeed not the one I'm very proud of... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
