Bug 233967

Summary:	YaST YOU: unsafe treatment of filenames (e.g. containing spaces)
Product:	[openSUSE] openSUSE 10.2	Reporter:	Ulrich Windl <Ulrich.Windl>
Component:	libzypp	Assignee:	Michael Andres <ma>
Status:	RESOLVED FIXED	QA Contact:	Stanislav Visnovsky <visnov>
Severity:	Major
Priority:	P5 - None	CC:	aj, andreas.hanke, crrodriguez
Version:	Final
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Ulrich Windl 2007-01-12 08:56:18 UTC

When trying to do an Online Update from a previously registered directory source, no update could be installed. Furthermore, even though no update had been installed, in a second attempt to install the updates, all updates were skipped, maybe due to inconsistent views regarding to what#s installed, and what's not.

Here are some details:
Updates were on a DVD with the Volume Label "SUSE Linux 10.1 Patch DVD" in side a directory "SL10.2-i386". Thus the path registered was "/media/SUSE Linux 10.1 Patch DVD/SL10.2-i386". What YaST did is this:
Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--' '/media/SUSE Linux 10.1 Patch DVD/SL10.2-i386/rpm/i586/openssl-0.9.8d-17.2.i586.rpm'

Naturally the result was like this:
Subprocess failed. Error: RPM failed: error: open of /media/SUSE failed: No such file or directory
error: open of Linux failed: No such file or directory
error: open of 10.1 failed: No such file or directory
error: open of Patch failed: No such file or directory
error: open of DVD/SL10.2-i386/rpm/i586/openssl-0.9.8d-17.2.i586.rpm failed: No such file or directory

Despite that updates work unreliable that way, it may also be a security problem when considering paths like "/my foo dir/ echo>/etc/passwd more_stuff.rpm".

Comment 1 Marcus Meissner 2007-01-12 09:25:52 UTC

libzypp problem i guess

Comment 2 Klaus Kämpf 2007-01-12 10:33:28 UTC

RPM backend probably needs more/proper quoting

Comment 3 Michael Andres 2007-01-15 11:23:08 UTC

IMO it's rpm related:

# rpm -Uvh WITH\ BLANK/test-1.0-0.intern.x86_64.rpm 
error: open of WITH failed: No such file or directory
error: open of BLANK/test-1.0-0.intern.x86_64.rpm failed: No such file or directory

# rpm -Uvh 'WITH BLANK/test-1.0-0.intern.x86_64.rpm'
error: open of WITH failed: No such file or directory
error: open of BLANK/test-1.0-0.intern.x86_64.rpm failed: No such file or directory

These forms should work.

Comment 4 Michael Schröder 2007-01-15 11:35:11 UTC

But they don't, and I won't make such an incompatible change. You need additional quoting.

Comment 5 Michael Andres 2007-01-15 12:44:57 UTC

fixed in libzypp-2.12.1

Comment 6 Ulrich Windl 2007-01-16 10:25:59 UTC

(In reply to comment #3)
> IMO it's rpm related:

RPM must have a very strange command line parser: I verified that processing is don in the C program. However these names don't work (are treated a two arguments):
file\ space.prm
"file space.rpm"
'file space.rpm'

This works:
'file\ space.rpm'
"file\ space.rpm"

Maybe reassign to component base system with a new description. Problem should be fixed in RPM with quite high priority.

Comment 7 Ulrich Windl 2007-01-16 10:35:16 UTC

(In reply to comment #5)
> fixed in libzypp-2.12.1

Did you verify (despite that it's a good idea to quite the filenames) that this fixes the problem? See comment #6.

Comment 8 Michael Andres 2007-01-18 13:57:50 UTC

(In reply to comment #6)
> 
> This works:
> 'file\ space.rpm'

That's the libzypp fix.


> Maybe reassign to component base system with a new description. Problem should
> be fixed in RPM with quite high priority.

See comment #4. I assigned it to mls because it should be fixed in RPM, but it won't.

Comment 9 Andreas Hanke 2007-01-18 14:13:34 UTC

See also: Bug 181275

This behaviour of rpm is a feature, double-quoting is the correct solution. rpm expects the user to do that.

Comment 10 Anja Stock 2007-01-22 09:35:37 UTC

released