Branch 'f18-branch' - 2 commits - imgcreate/kickstart.py Makefile
by Brian C. Lane
Makefile | 2 +-
imgcreate/kickstart.py | 11 ++++++-----
2 files changed, 7 insertions(+), 6 deletions(-)
New commits:
commit 49164d86c013b1d59314fb67a0a3d22d19b29b4b
Author: Brian C. Lane <bcl(a)redhat.com>
Date: Thu May 23 06:23:58 2013 -0700
Version 18.16
diff --git a/Makefile b/Makefile
index 791917f..ccd1bd4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
-VERSION = 18.15
+VERSION = 18.16
INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL}
commit 6f9b3a9bd9b9bb41bd4db9ea992685c27e1b6b66
Author: Tomas Hoger <thoger(a)redhat.com>
Date: Thu May 23 05:56:11 2013 -0700
Avoid setting empty root password (#964299)
When using kickstart with no rootpw command, imgcreate ended up calling
"passwd -d root", leaving the root account password-less. That may lead to
local or remote privilege escalation.
This change does the following:
1) There's no password manipulation done when password is empty string and
rootpw was not called with --iscrypted
2) Password is locked when "rootpw --lock" is used
Notes:
Users can still shoot themselves in a foot by using: rootpw --iscrypted ""
Resolves: rhbz#964299 (CVE-2013-2069)
Signed-off-by: Brian C. Lane <bcl(a)redhat.com>
diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py
index b12cd0c..1ed9f2f 100644
--- a/imgcreate/kickstart.py
+++ b/imgcreate/kickstart.py
@@ -199,9 +199,9 @@ class FirewallConfig(KickstartConfig):
class RootPasswordConfig(KickstartConfig):
"""A class to apply a kickstart root password configuration to a system."""
- def unset(self):
- self.call(["/usr/bin/passwd", "-d", "root"])
-
+ def lock(self):
+ self.call(["/usr/bin/passwd", "-l", "root"])
+
def set_encrypted(self, password):
self.call(["/usr/sbin/usermod", "-p", password, "root"])
@@ -224,8 +224,9 @@ class RootPasswordConfig(KickstartConfig):
self.set_encrypted(ksrootpw.password)
elif ksrootpw.password != "":
self.set_unencrypted(ksrootpw.password)
- else:
- self.unset()
+
+ if ksrootpw.lock:
+ self.lock()
class ServicesConfig(KickstartConfig):
"""A class to apply a kickstart services configuration to a system."""
10 years, 11 months
Makefile
by Brian C. Lane
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit d77deafcd74480f5ddb3cf4cb09c865eddaa4705
Author: Brian C. Lane <bcl(a)redhat.com>
Date: Thu May 23 06:18:04 2013 -0700
Version 19.3
diff --git a/Makefile b/Makefile
index 613b4d8..1bd9529 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
-VERSION = 19.2
+VERSION = 19.3
INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL}
10 years, 11 months
imgcreate/kickstart.py
by Brian C. Lane
imgcreate/kickstart.py | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
New commits:
commit d40ec8e9d8e8222196f5f7f60b38983489794a67
Author: Tomas Hoger <thoger(a)redhat.com>
Date: Thu May 23 05:56:11 2013 -0700
Avoid setting empty root password (#964299)
When using kickstart with no rootpw command, imgcreate ended up calling
"passwd -d root", leaving the root account password-less. That may lead to
local or remote privilege escalation.
This change does the following:
1) There's no password manipulation done when password is empty string and
rootpw was not called with --iscrypted
2) Password is locked when "rootpw --lock" is used
Notes:
Users can still shoot themselves in a foot by using: rootpw --iscrypted ""
Resolves: rhbz#964299 (CVE-2013-2069)
Signed-off-by: Brian C. Lane <bcl(a)redhat.com>
diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py
index b12cd0c..1ed9f2f 100644
--- a/imgcreate/kickstart.py
+++ b/imgcreate/kickstart.py
@@ -199,9 +199,9 @@ class FirewallConfig(KickstartConfig):
class RootPasswordConfig(KickstartConfig):
"""A class to apply a kickstart root password configuration to a system."""
- def unset(self):
- self.call(["/usr/bin/passwd", "-d", "root"])
-
+ def lock(self):
+ self.call(["/usr/bin/passwd", "-l", "root"])
+
def set_encrypted(self, password):
self.call(["/usr/sbin/usermod", "-p", password, "root"])
@@ -224,8 +224,9 @@ class RootPasswordConfig(KickstartConfig):
self.set_encrypted(ksrootpw.password)
elif ksrootpw.password != "":
self.set_unencrypted(ksrootpw.password)
- else:
- self.unset()
+
+ if ksrootpw.lock:
+ self.lock()
class ServicesConfig(KickstartConfig):
"""A class to apply a kickstart services configuration to a system."""
10 years, 11 months
imgcreate/yuminst.py
by Brian C. Lane
imgcreate/yuminst.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
New commits:
commit 7709a83f722ce314ab762581a1170ec8241cbd5b
Author: Brian C. Lane <bcl(a)redhat.com>
Date: Wed May 22 15:13:09 2013 -0700
Handle urlgrabber callback changes (#963645)
diff --git a/imgcreate/yuminst.py b/imgcreate/yuminst.py
index 6b1698f..31b2f36 100644
--- a/imgcreate/yuminst.py
+++ b/imgcreate/yuminst.py
@@ -36,8 +36,9 @@ class TextProgress(object):
hdlr.stream.write(msg)
hdlr.stream.flush()
- def start(self, filename, url, *args, **kwargs):
- self.emit(logging.INFO, "Retrieving %s " % (url,))
+ def start(self, filename=None, url=None, *args, **kwargs):
+ text = kwargs.get("text", "")
+ self.emit(logging.INFO, "Retrieving %s " % (url or text))
self.url = url
def update(self, *args):
pass
10 years, 11 months
MBR in livecd
by Gareth
Hi, developers
I'm now trying install a system on a disk, such as /dev/sda, in a livecd
environment.
I think I could just follow the steps of making a live cd without the
package step. It seems work, but I found there is no MBR settings during
making a livecd.
I also tried the 'iso-to-disk' script onto a disk. It's bootable, but
failed when finding a usb device.
I'm confused about the progress of setting correct MBR (to a grub, or to a
partition). Is there any clear steps to do that?
--
Gareth
*Cloud Computing, OpenStack, Fitness, Basketball*
*OpenStack contributor*
*Company: UnitedStack <http://www.ustack.com>*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
10 years, 11 months
understanding about function "create_image_minimizer"
by Gareth
Hi, all
I'm confused about the progress of this function. Actually in its steps:
1) Create a sparse COW
2) Loopback mount the image and the COW
3) Create a device-mapper snapshot of the image
using the COW
4) Resize the filesystem to the minimal size
5) Determine the amount of space used in the COW
6) Restroy the device-mapper snapshot
7) Truncate the COW, removing unused space
8) Create a squashfs of the COW
why not resize2fs -M osmin.img directly?
In document http://fedoraproject.org/wiki/LiveOS_image,
it said"osmin.img is a minimized OS image which is used to aid traditional
installation from a LiveOS image source to a hard disk.", but how does this
lvm snapshot help with installation to disk?
Is "os.fturncate this file(snapshot file *osmin*)" dangerously?
Thanks
--
Gareth
*Cloud Computing, OpenStack, Fitness, Basketball*
*OpenStack contributor*
*Company: UnitedStack <http://www.ustack.com>*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify. *
10 years, 12 months