Pushing forward with Onward.
robertmbaker at gmail.com
Wed Jun 17 16:19:02 PDT 2009
On Wed, Jun 17, 2009 at 3:59 PM, Robert
Connolly<robert at linuxfromscratch.org> wrote:
> I'm not sure. I don't even know the differences between gcc42 and gcc44, but
> in general newer gcc versions produce healthier systems, as long as the other
> packages are using compatible source code.
Ok. Well theres no harm in attempting a 4.4.0 build I suppose. I will
have a look at it when I begin again.
> Many distributions have patches to fix compiler warnings. After confirming the
> warning, I like to compare these with the package's cvs, and submit it a bug
> report if it's not in upstream, and observe the feedback. If it's in upstream
> then it's considered an upstream fix. Don't use these patches blindly,
> remember what happened with debian and ssl.
Oh lord say no more that paints a clear picture.
> Just pretty much enough to get the user on their feet.
> Replace suid-root with capabilities, giving enough examples and debugging tips
> so the user knows what to do with blfs packages. Same with grsecurity rules,
> have enough examples and debugging tips so blfs packages aren't a problem.
This will be a learning experience for me, but thats really what this
is all about anyway. I doubt I will come back around to this before I
build through the base system again.
> Add iptables to the rebooted system, and sshd, for users doing a remote build.
Yes and yes. I found this to be fairly frustrating myself, and ended
up adding them in for my temp tools. I also found myself needing a
text editor so I included vim. Any thoughts on including an editor?
> The package/file management system discussed before. It needs to be simple so
> that using it is easy and second nature.
I take it rpm and dpkg are a little too involved to meet your simple
requirement. If I recall correctly you were more concerned about
having recorded what files were introduced by what packages rather
than having a full fledged package manager/build system. Correct me if
I am wrong.
> Adding fcron to the final system is a good idea. This can do log rotations,
> reseed /dev/erandom, clean /tmp, with /etc/daily and /etc/weekly scripts.
> Nothing crazy.
Would you also want to include logrotate or is there a better way of
handling log rotations that I have somehow missed?
> With posix capabilities daemons don't need privilege separation anymore. I
> haven't looked into this though. Debian has a 'runas' program that is
> basically like 'su -c foo bar' but it cleans the environment too. 'env -i
> su -c /usr/sbin/sshd sshd' might work. Daemon program files with capabilities
> need to be readable only by owner and group, not other, with the daemon user
> in the group.
If that is true for most daemons this should be fairly easy to get a
handle on. I am sure there will be some curve balls as usual, but such
> Grsecurity could use a little more tightening, by adding a networking group
> and only allowing that group to open sockets. Trusted path execution might
> become unusable with the file management user owning every system file and
> directory, but there may be a way to workaround or fix it.
I like the idea of limiting access for opening a sockets. Forgive me
if I am just not aware of an example, but I don't recall any package
manager requiring system files be owned by anyone other than specific.
All of them that I am fimiliar with require root to do darn near
anything. If your interested I would like to hear more about what you
envision the package management system to be for HLFS.
> A while ago I tried to get libcap added to BLFS, but libcap was not maintained
> at that time, and needed a lot of patches to build, so BLFS decided against
> it. Libcap2 is maintained now, and I think BLFS would add it. They have
> enough to do without libcap, so we should maintain this for them. Almost
> every daemon in BLFS can use capabilities to drop root. After the initial
> patch, the maintenance should be as simple as upgrading the libcap2 package,
> and adding it to new blfs daemon's from time to time. The initial patch will
> be a major pain, involving installing every single blfs package with
> suid-root programs and root daemons. This is all of gnome, kde, and pretty
> much everything else. After a few of us do this, and confirm it works, I
> think we'd have a stable hlfs candidate.
> --warn-shared-textrel --fatal-warnings causes a build failure if mktemp() or
> tmpnam() are used. This affects a few blfs packages. I have patches for the
> packages I found. Hopefully blfs will accept these patches, otherwise they go
> to blfs wiki.
Sounds like the whole process will come to a head outside of the book
at some point. Thats completely reasonable. I like this idea better
than just assuming the user will have picked up what they need through
osmosis by the time they complete the base system. I would be happy to
run down blfs packages once we are further along with the base system.
> I don't think we've come this far to slap a "stable" sticker on whatever we
> have and promote it. Everything needs to be checked ten times, then continue
> to the next task, until everything is done, then check it again. Then use
> the "we did it" sticker.
I agree. I really just wanted to pick your brain to see what you had
in mind for a stable release. It sounds to me like you have thought it
through quite a bit. There is definitely a good deal of work to be
done, but things appear to be heading in the right direction.
More information about the hlfs-dev