Red Hat Bugzilla – Bug 557655
guestfish number parsing should not use atoi, should support '0...' for octal and '0x...' for hexadecimal
Last modified: 2010-03-16 13:26:13 EDT
Description of problem: guestfish interprets the mode argument of chmod in decimal rather than octal. Version-Release number of selected component (if applicable): 1.0.75-1 How reproducible: Always Steps to Reproduce: 1. Run "chmod 700 /" in guestfish. Actual results: / gets permissions -w-rwxr-T (1274 octal = 700 decimal) Expected results: / gets permissions rwx------ Additional info: "chmod 0700 /" doesn't work correctly either.
Yes I agree this is a bug. At the moment the code does: mode = atoi (argv[0]); which is wrong on several levels.
Jim, it seems sensible to ask which gnulib function I should be using here.
Hi Rich, xstrtoul should do the trick.
Patch posted upstream: http://www.redhat.com/archives/libguestfs/2010-January/msg00020.html
This still violates the principle of least surprise. The chmod command-line program doesn't require the leading 0, so users will omit it here too and will get nonsensical file modes. Is it really useful to be able to specify file modes in decimal or hex?
See: http://libguestfs.org/FAQ.html#rescue We can cover this in the documentation, but guestfish isn't like bash, and chmod in guestfish is a wrapper around guestfs_chmod, not the chmod program, so it behaves a bit differently (but consistent with other guestfish commands).
I updated the patch to add a note to the 'chmod' command in the guestfish manual page.
Updated patch posted upstream: http://www.redhat.com/archives/libguestfs/2010-January/msg00022.html
Fixed upstream: http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=58abe782bf7137526b4a5c7e6d5d2b145e3b09d2 This fix will be in 1.0.82.