Chris Karakas dijo [Tue, Nov 25, 2008 at 10:39:23AM +0100]: > Hello all, > > I definitely oppose the proposed patch and will NOT accept it in chm2pdf (I > am one of the two authors)! > > Reasons: > > 1) There are easier ways to avoid the security risks. > 2) It destroys the "--dontextract" option which is a *very* useful one! > > Let me propose an alternative: > > It all has to do with using "tmp" in these 2 lines, right? > > CHM2PDF_TEMP_WORK_DIR='/tmp/chm2pdf/work' > CHM2PDF_TEMP_ORIG_DIR='/tmp/chm2pdf/orig' > > So, what would you say if I changed "tmp" to $HOME in the above two > lines? Any security concerns here? This way, we keep sane names for > the directories, we don't touch tmp, the user and only the user has > full control of the directories created - and we can keep the > --dontextract option! > > Any objections - or suggestions :-) - before I start coding?
Umh... I don't think that will do in many scenarios. I am not familiar with your code (I only stumbled upon this bug report), but please keep in mind that programs such as this one might often be called by a user with no writable home directory - Say, web-based processes. Most authors agree to use secure, unpredictable tempdir functions, available basically on every language, such as the one suggested by Raphael. I would recommend you to: - Default to Raphael's suggestion - Include a command line switch, so that the user can specify the tempdir (or PDF build dir, or whatever nomenclature you find suitable). > PS.: Before you kill me about the use of tmp, bear in mind that this > tool was created with the "normal user" in mind (me! :-)))), > i.e. for a system where 99% of the time only one user is using > it. That user was assumed to (be able to) change the value of the > CHM2PDF_TEMP_* variables to whatever fits him - that's why the > variables were actually created. Now people start complaining about > "malicious users". Oh well...you are all so right - but notice what: > we have already stopped talking about how to make the program do its > actual job better - we are talking about "cross-cutting concerns"! > That is, we now concentrate our energy *not* on the problem we > originally had to solve (CHM to PDF conversion), but on things like > "where to put the working dir, in /tmp, in $HOME or > elsewhere...". :roll: Well... That's the role of a distribution's QA, isn't it? ;-) We trust you to be the best person to implement the hard logic and little details behind it all, but please trust us when advicing on how most users install their software, at least in Debian settings. Why so much insistence? First, because if the software is shipped as part of Debian, a user cannot modify the variables (i.e. the program will be installed in /usr/bin, owned by root, and not writable by any system user). Second, most users (and the proportion is growing!) are not proficient in Python, nor interested in learning how to program, and, even if I don't like the idea, will just be scared at the idea of opening a program source in a text editor. Yes, I know many of those users will have a single-user system. But still, Linux distributions _still_ have (and will continue to) large numbers of multi-user settings (i.e. school/university labs, or company-wide managed terminals, and a very large etcetera - Even a household with several different users!) As a distribution, it is our task to ensure all the user cases are satisfiable the best way possible... even if that's not what you originally intended. Of course, you are free not to incorporate a patch in your sources - but that will only mean we will keep it as a patch (and behaviour difference) in our packaging. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
