Onward branch

Chris Buxton cbuxton at menandmice.com
Fri Sep 12 20:41:45 PDT 2008

Hash: SHA1

One note about the package users system: It doesn't work with uClibc.  
With that library, there is an effective limit on the number of  
members of a group - I forget the value, but it was something like 25  
or 50. I remember the package users system exceeded that for the  
install group.

Chris Buxton
Professional Services
Men & Mice

On Sep 12, 2008, at 6:38 PM, Robert Connolly wrote:

> 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
> helper.
> 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
> organized.
> robert
> -- 
> http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

Version: GnuPG v1.4.8 (Darwin)


More information about the hlfs-dev mailing list