Onward branch

Robert Connolly robert at linuxfromscratch.org
Fri Sep 12 18:38:16 PDT 2008

On Friday September 12 2008 02:38:43 am Jan Dvorak wrote:
> On Friday 12 September 2008 02:14:33 Robert Connolly wrote:
> > Some daemons still run as root, even with privilege separation, like
> > fcron, dhclient, etc.
> fcron has to run with full set anyway, or not?

Almost always no. crond only needs to do what you need it to do. If the only 
thing in root's crontab is to run /sbin/ldconfig, then almost all 
cababilities can be removed.

In practice we can disable all capabilities on /usr/sbin/fcron, try to start 
it, and from the errors we can figure out the minimum capabilities it needs. 
Normally, fcron would not need the capability of loading kernel modules, for 
example. Grsecurity can nail it down futher.

As far as I know, any process running as root can have some of its 
capabilities stripped and work properly after. The reverse works too, in that 
a normal user could run a daemon with some of root's capabilities. With 
enough trial and error, even udevd and agetty can run as non-root users, or 
root with limited capabilities.

None of these daemons needs all the privileges of a root shell, like having 
write permission on every file.

I want to write a set of rules for the onward-branch (new trunk) wiki/book... 
like don't add packages with suid-root until you have caps or grsecurity 
rules (or both) to limit it, don't break test suites by upgrading or adding 
patches (fix the testsuite if you have to), add as many details/comments as 
possible to all patches (especially origin). Start over, again, but better 
prepared this time.

> > Installing packages as regular
> > users would limit this, so I think it'd be a good idea to integrate the
> > more_control_and_pkg_man.txt in the final system.
> I've had two systems with package users ~2 years back. One of them being
> HLFS. You don't want to do that, believe me, you don't want it. Besides,
> if you insist on having binaries installed as non-root, you have
> historical user called bin for this.

I don't know of competitive alternative.

Everything could be installed at user 'bin'. This doesn't stop files from 
being overwritten, but it's a step in the right direction.

Installing as a package-installer-user, like the more_control_and_pkg_man hint 
does, makes it easy to identify all new files for backups or checksums (with 
find(1)), without any advance information about exactly what files will be 
installed. If you're creating a package, from scratch, this is the best 
system to use.

This is not package management, it's filesystem management.

The more_control_and_pkg_man.txt hint system is tedious, but it identifies 
every problem with filesystem permissions and packages, for us. It's a big 

I admit that this starts getting very complicated on multi-purpose systems 
like a desktop, but it can be done one step at a time. It needs to be well 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080912/a143e8fb/attachment.sig>

More information about the hlfs-dev mailing list