[prev in list] [next in list] [prev in thread] [next in thread] 

List:       inn-workers
Subject:    Re: items in LIBDIR (related to FHS patch)
From:       Russ Allbery <rra () stanford ! edu>
Date:       2001-04-25 14:35:36
[Download RAW message or body]


James Ralston <qralston+ml.inn-workers@andrew.cmu.edu> writes:
> On 20 Apr 2001, Russ Allbery wrote:

>> Oh, this reminds me.  Make sure that anything that's installed in
>> /usr/bin is *not* owned by news.  Anything that's on root's path should
>> be installed owned by root, since otherwise it's too easy for the news
>> user to break into root.  This will require some fiddling with the
>> installation rules, unfortunately.

> Urk.

> Would it be acceptable to install all programs in PATHBIN as user root,
> regardless of whether --eable-fhs-dirs was provided?  This shouldn't
> affect anything in a non-FHS install anyway, because in a non-FHS
> install, nothing in /usr/bin is editable or configurable at all.

Unless you do it very carefully, that makes it much more difficult for
someone to install INN as a non-root user, which up until now has been
possible provided that you don't need to use the standard news ports.

> In short, they're a big pain.  To paraphrase the FHS:

>     /usr/bin:

> 	Anything that is meant to be executed directly by regular
> 	users.

>     /usr/sbin:

> 	Anything that is meant to be executed directly by non-regular
> 	users (the superuser, system administrators, other system-type
> 	accounts, etc.).

You can probably get a first pass on /usr/bin vs. /usr/sbin by looking at
whether the manual page for the program is in .1 or .8.  Sometimes this
isn't accurate; I've been fixing problems as I see them, but there are
some that I haven't gotten to yet.

> Unfortunately, INN probably needs all 3 of /usr/bin, /usr/sbin, and
> /usr/lib/news/bin.

Yup.

> An example for /usr/lib/news/bin is parsecontrol.  This program is
> invoked exclusively by the control programs.  There's no reason this
> program should be in /usr/bin or /usr/bin; it belongs in
> /usr/lib/news/bin.

> An example for /usr/sbin is makehistory.  This program is never invoked
> automatically by any subsystem of INN; it is intended to be run manually
> by the news administator, or by a script of some sort written
> specifically to automate its invocation.  It doesn't belong in
> /usr/lib/news/bin because it's manually invoked, but since it's useless
> for regular users it doesn't belong in /usr/bin.

> An example for /usr/bin is convdate.  In the past, I've found convdate
> useful enough that I've ripped it out of INN and put it in my own ~/bin
> directory.  This program is always manually invoked (so far as I can
> tell), and it's perfectly useful for regular users.  It belongs in
> /usr/bin.

Yup.  I agree with all of that.

> The way I'm thinking of solving this issue is to fork BINDIR into three
> directories: BINDIR, SBINDIR, and LIBBINDIR.  In a non-FHS build, they'd
> all have the same value (/usr/local/news/bin by default).  In an FHS
> build, they'd be set to /usr/bin, /usr/sbin, and /usr/lib/news/bin,
> respectively.

That's fine with me.

> I'm certainly open to suggestions, though.

> BTW, I notice that TODO has this entry:

>   * Add a separate utils directory for things like convdate, shlock,
>     shrinkfile, and the like.  Some of the scripts may possibly want
>     to go into that directory too.

> This sounds to me like you want the non-FHS equivalent of /usr/bin: you
> want a directory to place tools that INN uses, but which aren't
> specifically tied to INN, and might be usable by others.  Is that
> correct?  Perhaps we can kill two birds with one stone here...

You're misunderstanding that section of the TODO file; I should probably
add something in there to clarify.  That's talking about organization of
the source code tree, which is independent of where things are installed.

> Ok, the new name will be libinnstorage.

Any worries that's too long of a name?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

[prev in list] [next in list] [prev in thread] [next in thread]