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).
-D
Date sent: Sun, 03 Jun 2007 22:01:05 -0400
From: Robert Connolly <[EMAIL PROTECTED]>
Subject: Re: system file ownership
To: Hardened LFS Development List <hlfs-
[EMAIL PROTECTED]>
Send reply to: Hardened LFS Development List <hlfs-
[EMAIL PROTECTED]>
<mailto:hlfs-dev-
[EMAIL PROTECTED]>
<mailto:hlfs-dev-
[EMAIL PROTECTED]>
> 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
>
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
