Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 22 Aug 2013 14:43:03 +0400
From: Solar Designer <>
Subject: Re: some issues encountered in Owl-3_0-stable-20130408-i686.iso.gz


On Thu, Aug 22, 2013 at 12:09:27PM +0200, John Spencer wrote:
> yesterday i did an owl test install in order to compare its filesystem 
> permissions with that of my own distribution i'm working on.
> i encountered a couple of (mostly minor) issues, which i'm documenting 
> here... feel free to ignore.

Thanks for reporting these!  I think this is mostly owl-users rather
than owl-dev material, but I'll respond in here since the message is
already on owl-dev.

I think Owl-current would have been a (slightly) better choice for your

> 1) when run in virtual box with default settings, the kernel will detect 
> a non-SMP system and lock up after some PCI diagnostic messages.
> assigning more than one CPU to the VM fixes that.

Ouch.  I think it's the first time this is reported.  Do you have a
suggested fix?

> 2) the documentation says that for installation "setup" and "settle" 
> should be used.

Not exactly.  It says (or tries to) that if you install remotely, you
might find it more convenient to configure the live system with "setup"
first and then proceed with the actual install from a remote workstation
with "settle".  In other scenarios, you probably won't find this
possibility useful and would proceed with "settle" right away.

In practice, we found this approach useful when asking a third-party
(such as a data center technician) to configure the live system for us
(with "setup"), so that we can proceed with the actual install ourselves
(using "settle").

Maybe the documentation is not clear enough.

> however settle does not detect changes done using setup, 
> so you end up having to assign a root password twice.
> i also changed my keyboard layout with setup, (and not in settle), so
> after the install my keyboard layout was still USA, which came as a 
> surprise (detected when the ":" did not work, so i couldnt exit vi).

Actually, both utilities detect the current system's networking
settings (thus, "settle" will pick up the networking settings prepared
with "setup"), but IIRC not anything else.  And you'll need to enter the
networking settings sub-menu and "save" the settings.

I'm not sure if we need to change that.

> 3) the passwd utility does not allow setting a weak password.
> i understand that it somehow makes sense to enforce good security,
> but OTOH on test installations that will never ever connect to a real
> ethernet cable you really don't want a 20 letter password.
> in my sysadmin past, more than 90% of linux installs were test 
> installations.
> i ended up copy/pasting a weak password hash manually into 
> /etc/tcb/root/shadow...
> imo there should be a way to make passwd do what the admin wants without 
> forcing him to edit the shadow file.

As an alternative, you could have edited /etc/passwdqc.conf changing
enforce=everyone to enforce=users.

Personally, I find it easy to come up with and type a password that
passes the checks, even for test installs.  It does not have to be 20
letters.  You may use e.g. 3 short words with a combined length of 11
characters (including whitespace) or more.

> 4) after the install, the Owl documentation is nowhere to be found.
> apparently it's only on the CD-ROM media. imo it should be installed on 
> hdd and the /etc/motd as well.

Yes, maybe.

> 5) adduser user ; su user
> bash: /root/.bashrc: Permission denied

Isn't this normal?  You use "su - user" to more fully switch to the
user's environment.

> 6) very old find utility
> i used the following command to search for world writable files:
> find / ! -type l -perm -002  2>/dev/null
> turned out that the ancient installed version does not even support the 
> ! type syntax, so it appeared as if Owl has no world-writable files at 
> all...
> (btw, even current busybox find supports all options in that find statement)

You probably did something wrong in that test.  What shell were you
using?  Did it possibly interpret the "!" character itself?

While our version of findutils is not very recent, it is also not that

> 7) very old gcc

Owl-current has newer gcc.

> it's not even possible to build a kernel with a GCC that old.

Depends on kernel version. ;-)  Anyway, to build recent kernels you need

> and indeed when looking at 
> it appears as if a good part of the patch are compiler version 
> workarounds. while i personally like having a patch for old gcc versions 
> and a recent kernel, in this case it only adds unwanted noise to the 
> patch. but then, maybe there's a better place to look for the single 
> patches openwall applies to the kernel (lots of small topic patches) ?

No, we don't maintain broken-out patches.  That -owl patch is not large,
and is easier to apply as one patch when people do custom kernel builds.

As you have noticed, we do still keep some workarounds for old gcc
versions in the kernel -owl patch in Owl-current, but they only matter
when building similar kernels on Owl 3-stable.  We'll drop them in
Owl-current along with the move to RHEL6'ish kernels.

> 8) lacking the documentation after the system was installed,
> i tried to find out how to install an usable editor (gnu nano).
> as it's a rpm based install, i tried to use yum, but it is not
> existant. my suggestion is to create yum as a shell script
> which justs prints the right information how to install stuff on owl.
> $ yum install nano
> this system uses XXX for package install, try XXX install nano instead.

Frankly, there's no very good answer that we could have this script
print right now.  We need to update things first, so that we could
recommend the use of an up-to-date third-party repository (rather than
something outdated like CentOS 4, which sort of works, but is not
something we'd recommend now) or our own (future) repository.

> 9) since nano is the default editor in debian and ubuntu, i think owl
> should ship it in the default install as well.

Yes, we should add nano, although personally I find VIM more convenient
(and am annoyed with the Debian/Ubuntu default).


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ