Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.79 [en] (Win98; U) Description of problem: The "password='mypass'" linein script.cfg is not encrypted nor encoded. This causes smbprint to fail if the password contains any shel metacharacters (as a good password should). The single quotes generated around the password don't help since the password may contain single quotes, and in any case is "eval"ed later which cancels the effects of the quotes. Additionally, there is a security hole whenn storing plain text versions of passwords: if the script.cfg file is compomised a username and password can be obtained. Additionally the "share='\\server\printer'" entry must encode the backslashes as forward slashes in the UNC share name. The eval of the result cancels the effect of the single quotes. (the back-slashes could alternatively be escaped with additional backslashes, as in "share='\\\\server\\printer'". Version-Release number of selected component (if applicable): Current versions as of 6/4/02 (ran up2date this morning and verified bug still present and not previously listed in Bugzilla) How reproducible: Always Steps to Reproduce: 1.Use either printconf-gui or printconf-tui 2.Select an SMB queue 3.Use a password containing a single quote or other shell metacharacters Actual Results: No output is produced Expected Results: Output should have been printed Additional info: Suggested solution: The password could be encrypted with MD5 and a randomly generated (at RH install time) password stored in a file not world-readable. Then your tools could store the encrypted password in script.cfg, and decrypt in RAM when invoking smbprint. This solution doesn't require using SMB encrypted passwords. As for the share name, some simple Python (or a pass using tr) will easily solve the issue. (Additional details of this soluiton such as updating existingscript.cfg entries are left as an exersize for the reader.) An interim solution would include adding a string to the printconf dialogs warning users to use forwad slashes in UNC names, and to use passwordfs without any shell metacharacters for SMB passwords. But this wouldn't address the security aspect of storing plaintext passwords on the disk.
When I tried this on Red Hat Linux 7.3 a short while ago I thought this had been fixed. I'll re-check. Regarding the permissions on the file: it resides in a directory that only the 'lp' user may access.
If this is fixed in 7.3, could the 7.3 package be added to an otherwise 7.2 system? I realize the directory is protected, but it seems to me still a security hole to store plaintext passwords, especially when it would be so ease to encrypt them first.
In theory, yes, the package could just be upgraded. In practice, printing has lots of dependencies, so you might end up pulling in more than you want. Let me check if it really is fixed, and I'll update this bug entry appropriately. Yes, ideally it would be encrypted as well.
Single quotes are now dealt with in CVS.
Fixed package is 0.4.1-1.