system file ownership

Darren McGrandle darren at
Sun Jun 3 23:12:14 PDT 2007

You might want to check out the More Control Package Users hint in 
lfs, a good chunk of the work to make this doable has already been 
done.  This also exposes things like packages making their 
executables suid 'behind the back' during make install.

Done properly, almost nothing is owned by root (except some 
directories and config files).


Date sent:	Sun, 03 Jun 2007 22:01:05 -0400
From:	Robert Connolly <robert at>
Subject:	Re: system file ownership
To:	Hardened LFS Development List <hlfs-
dev at>
Send reply to:	Hardened LFS Development List <hlfs-
dev at>
request at>
request at>

> To expand on this thread. I've always thought it would be a good idea to do 
> all the builds as non-root. None of the builds need root privileges, and it's 
> not a good habit to be logged in as root doing things that a normal user can 
> do.
> With /tools/bin/su installed for the Coreutils and Bash test suites, su can 
> also be used to drop down to the 'system' user (who does not have a 
> password), who owns the majority of the public directories and files.
> There's a issue with the uid being for a different user inside and outside the 
> chroot, but something like 'uid 1' is almost never a login user, so it 
> shouldn't be a problem.
> This was discussed on this list years ago, and it was thought that the root 
> account is better guarded than the others, and so files owned by root would 
> also have better protection. But if we consider that root's superuser file 
> modification capabilities can be dropped with suid programs, then there's an 
> advantage to breaking up administrative privileges into different users and 
> roles.
> robert

More information about the hlfs-dev mailing list