Pushing forward with Onward.
robert at linuxfromscratch.org
Wed Jun 17 17:40:20 PDT 2009
On Wednesday June 17 2009 07:19:02 pm robert baker wrote:
> 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.
Some patches don't apply to gcc-4.4.0. See:
I don't really maintain this directory, I just upload new patches to it. Don't
use these patches as Bible, but in general the newest patch should work.
Patches in this directory are being worked on for some reason, and are not
> > 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?
If the book is working, then Vim is not needed. If you need it, then install
> > 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.
I refuse to take sides in the package manager debate, but I need file
The system would be owned by user 'bin' (for example). New installs would be
done by "installer" (for example). The "installer" user is in the "bin"
group, and has write permission to system directories. New package files are
recorded after each 'make install', and ownership is changed to the 'bin'
user. The 'installer' user can't overwrite files owned by 'bin'.
We don't create binary packages.
For upgrades, you have a file list belonging to the old package, so they can
be removed before 'make install'. This may be complicated with Coreutils, but
we can work that out by allowing new packages to overwrite existing files
The idea is that we know which package every file belongs to. Also, no file is
owned by root, so a daemon running as root does not have the capability of
overwriting files not owned by root. Even the loop0 process, or kjournald,
can drop posix capabilities so it can not overwrite another user's files
(files not owned by root).
This is a huge part of the file management system. Root loses a lot of power
with this system.
> > 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?
Perhaps, but I'm not familiar with the logrotate package, and do not see how
it would be better than an shell script.
> > 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 process running as root, uid 0, can have the CAP_FOWNER capability removed.
This would disallow the process running as root from changing files that are
owned by another user.
I'm tired, and may have missed something.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the hlfs-dev