Re: FHS: Where to store user specific plugins / code

[Georg Faerber]

Hi Jonas,

On 18-03-09 19:18:50, Jonas Meurer wrote:
> Am 09.03.2018 um 14:23 schrieb Georg Faerber:
> >> Ian's comments are good for admin-installed plugins that the users can
> >> use.  In fact there is good precedent for an app checking
> >> /usr/lib/pkg/... for plugins installed from Debian packages,
> >> /usr/local/lib/pkg/... for plugins installed by the admin from
> >> non-Debian locations, and then finally the user's .config/pkg/...
> >> directory.
> > 
> > I guess we'll go with /usr/local/lib/schleuder then? Does this sound
> > like a reasonable choice?
> 
> I don't think it's allowed for Debian packages to create subdirectories
> under /usr/local, is it?

According to the policy, that's allowed [1]:

"As mandated by the FHS, packages must not place any files in
/usr/local, either by putting them in the file system archive to be
unpacked by dpkg or by manipulating them in their maintainer scripts.

However, the package may create empty directories below /usr/local so
that the system administrator knows where to place site-specific files.
These are not directories in /usr/local, but are children of directories
in /usr/local. These directories (/usr/local/*/dir/) should be removed
on package removal if they are empty.

Note that this applies only to directories below /usr/local, not in
/usr/local. Packages must not create sub-directories in the directory
/usr/local itself, except those listed in FHS, section 4.5. However, you
may create directories below them as you wish. You must not remove any
of the directories listed in 4.5, even if you created them."

Cheers,
Georg


[1] https://www.debian.org/doc/debian-policy/#site-specific-programs


signature.asc
Description: Digital signature

Re: FHS: Where to store user specific plugins / code

[Enrico Weigelt, metux IT consult]

On 09.03.2018 14:23, Georg Faerber wrote:

Hi, > I guess we'll go with /usr/local/lib/schleuder then? Does this 
sound> like a reasonable choice?

That would be my choice.

OTOH, it might be nice to have a helper that automatically creates
deb packages. (would also be nice for other applications, eg. moz).


--mtx

--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: FHS: Where to store user specific plugins / code

[Jonas Meurer]

Am 09.03.2018 um 14:23 schrieb Georg Faerber:
>> Ian's comments are good for admin-installed plugins that the users can
>> use.  In fact there is good precedent for an app checking
>> /usr/lib/pkg/... for plugins installed from Debian packages,
>> /usr/local/lib/pkg/... for plugins installed by the admin from
>> non-Debian locations, and then finally the user's .config/pkg/...
>> directory.
> 
> I guess we'll go with /usr/local/lib/schleuder then? Does this sound
> like a reasonable choice?

I don't think it's allowed for Debian packages to create subdirectories
under /usr/local, is it?

You could still read in plugins from this path in case it exists and
document that users ... aehm, admins ... shall create it and put their
plugins there.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Re: FHS: Where to store user specific plugins / code

[Georg Faerber]

Hi,

On 18-02-28 18:14:17, Marvin Renich wrote:
> If a user get to install his/her own plugins, they should go in the
> user's home directory, e.g. /home/user/.config/scheduler/plugins/.
> Non-root users should not generally be given write permission to
> /usr/local, and definitely not to /usr/lib.

See my separate mail: The term "user" used by me was misleading, I
guess, more appropriate would have been "admin".

> If the app takes care of installing the plugins on the user's behalf,
> that is slightly different.  However, if the plugin can be selected by
> the user from a non-trusted source, I would still go with the user's
> directory.  Allowing a non-root user to put his own plugin where
> others can execute it without being able (even required) to verify its
> integrity is a huge security hole.

The app doesn't take care of installing the plugins. This would be the
job of the admin, using whichever technique they're comfortable with.

> Ian's comments are good for admin-installed plugins that the users can
> use.  In fact there is good precedent for an app checking
> /usr/lib/pkg/... for plugins installed from Debian packages,
> /usr/local/lib/pkg/... for plugins installed by the admin from
> non-Debian locations, and then finally the user's .config/pkg/...
> directory.

I guess we'll go with /usr/local/lib/schleuder then? Does this sound
like a reasonable choice?

Thanks,
Georg


signature.asc
Description: Digital signature

Re: FHS: Where to store user specific plugins / code

[Georg Faerber]

Hi,

On 18-03-01 07:55:08, Peter Silva wrote:
> -- it is best practice for daemons/services not to run as root.  They
> should have an application specific user.

Schleuder does use a dedicated user, called schleuder. $HOME is set to
/var/lib/schleuder. Inside there mailing list specific data is stored.

Cheers,
Georg


signature.asc
Description: Digital signature

Re: FHS: Where to store user specific plugins / code

[Georg Faerber]

Hi all,

Thanks for your replies, and sorry for the delay in answering.
(Note to myself: Don't write such mails while traveling..)

That said, I think I wasn't clear regarding "user specific":

On 18-02-28 18:54:14, Georg Faerber wrote:
> Currently, we allow users to run / execute their own plugins, stored
> in /etc/schleuder/plugins. Obviously, that's not the right place, as
> /etc is for config files, not executable code. We would like to fix
> this, but are unsure which location to offer. The (empty) directory
> would be provided by the package, but the (possible) content would be
> provided by the user.
> 
> Therefore, I'm wondering what's the correct place: Would
> /usr/local/lib/schleuder/plugins be sensible? If not, any other place
> which is more suitable?

Using "user" I meant not the real "end-users", sending mail, but the
"user" (an admin running a mailserver) who installs schleuder.

Cheers,
Georg


signature.asc
Description: Digital signature

Re: FHS: Where to store user specific plugins / code

[Guillem Jover]

On Wed, 2018-02-28 at 18:14:17 -0500, Marvin Renich wrote:
> * Ian Jackson  [180228 17:45]:
> > Georg Faerber writes ("FHS: Where to store user specific plugins / code"):
> > > Currently, we allow users to run / execute their own plugins, stored in
> > > /etc/schleuder/plugins. Obviously, that's not the right place, as /etc
> > > is for config files, not executable code. We would like to fix this, but
> > > are unsure which location to offer. The (empty) directory would be
> > > provided by the package, but the (possible) content would be provided by
> > > the user.
> > > 
> > > Therefore, I'm wondering what's the correct place: Would
> > > /usr/local/lib/schleuder/plugins be sensible? If not, any other place
> > > which is more suitable?

> > Do plugins do something which people might not want if present, and
> > not configured ?  If so then perhaps you want a thing a bit like the
> > apache mods-enabled scheme: a link farm.
> > 
> > If not, then if it's easy to do I would load all plugins in
> > /usr/local/lib/schleuder/plugins
> > /usr/lib/schleuder/plugins
> > (former masking the latter with for with the same name)
> 
> If a user get to install his/her own plugins, they should go in the
> user's home directory, e.g. /home/user/.config/scheduler/plugins/.

Definitely not under .config, for the same reasons it would be wrong
for those to go under /etc.

From the XDG Base Dir spec, the thing that's somewhat closest is
$XDG_DATA_HOME with a default of $HOME/.local/share. But that spec is
lacking in many places, and a missing .local/bin and .local/lib are
among those.

There are the logical extensions for those at
, but
unfortunately nothing seems to refer to XDG_LIB_HOME on sources.d.o. :(

Thanks,
Guillem

Re: FHS: Where to store user specific plugins / code

[Peter Silva]

another option:

-- it is best practice for daemons/services not to run as root.  They
should have an application specific user.

-- some tools can be run in a systemish way by a specific user, but
also by other users in a less official way (think web server on a high
port instead of port 80.)

-- user preferences are standardized by freedesktop.org
   https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html

So preferences/plugin settings would go under ~/.config/package/ for
whatever user is running the tool.
state files under ~/.cache/package/   The systemd.service file will
have User=, so the "normal"
service settings will be under ~.

It seems much cleaner to me than the httpd link farms, and allows
users to spin up their own daemons
(user httpd on a high port) with a natural location for settings.
This aligns with systemd where they have the --user flag to let users
manage their own daemons.












On Thu, Mar 1, 2018 at 7:26 AM, Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> Marvin Renich writes ("Re: FHS: Where to store user specific plugins / code"):
>> [stuff]
>
> I agree completely with Marvin's message.
>
> Ian.
>

Re: FHS: Where to store user specific plugins / code

[Ian Jackson]

Marvin Renich writes ("Re: FHS: Where to store user specific plugins / code"):
> [stuff]

I agree completely with Marvin's message.

Ian.

Re: FHS: Where to store user specific plugins / code

[Weldon]

 On Wed, 28 Feb 2018 09:54:14 -0800 Georg Faerber ge...@riseup.net 
wrote 




 

Therefore, I'm wondering what's the correct place: Would 

/usr/local/lib/schleuder/plugins be sensible? If not, any other place 

which is more suitable? 

 




If they're binaries, the FHS answer is that they go in /usr/libexec, but I 
don't think Debian even has that anymore. /usr/lib/schleuder/$PLATFORM would be 
consistent with a lot of other packages (e.g. gcc); FHS says each application 
can get 1 folder in /usr/lib and can put platform-specific folders under that. 
I'd shy away from doing anything at all to /usr/local, since there's an 
implicit (or even explicit?) promise that dpkg won't ever touch that.

WMG

Re: FHS: Where to store user specific plugins / code

[Marvin Renich]

* Ian Jackson  [180228 17:45]:
> Georg Faerber writes ("FHS: Where to store user specific plugins / code"):
> > I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list
> > manager with resending-capabilities".
> > 
> > Currently, we allow users to run / execute their own plugins, stored in
> > /etc/schleuder/plugins. Obviously, that's not the right place, as /etc
> > is for config files, not executable code. We would like to fix this, but
> > are unsure which location to offer. The (empty) directory would be
> > provided by the package, but the (possible) content would be provided by
> > the user.
> > 
> > Therefore, I'm wondering what's the correct place: Would
> > /usr/local/lib/schleuder/plugins be sensible? If not, any other place
> > which is more suitable?
> 
> Do plugins do something which people might not want if present, and
> not configured ?  If so then perhaps you want a thing a bit like the
> apache mods-enabled scheme: a link farm.
> 
> If not, then if it's easy to do I would load all plugins in
> /usr/local/lib/schleuder/plugins
> /usr/lib/schleuder/plugins
> (former masking the latter with for with the same name)

If a user get to install his/her own plugins, they should go in the
user's home directory, e.g. /home/user/.config/scheduler/plugins/.
Non-root users should not generally be given write permission to
/usr/local, and definitely not to /usr/lib.

If the app takes care of installing the plugins on the user's behalf,
that is slightly different.  However, if the plugin can be selected by
the user from a non-trusted source, I would still go with the user's
directory.  Allowing a non-root user to put his own plugin where others
can execute it without being able (even required) to verify its
integrity is a huge security hole.

Ian's comments are good for admin-installed plugins that the users can
use.  In fact there is good precedent for an app checking
/usr/lib/pkg/... for plugins installed from Debian packages,
/usr/local/lib/pkg/... for plugins installed by the admin from
non-Debian locations, and then finally the user's .config/pkg/...
directory.

...Marvin

Re: FHS: Where to store user specific plugins / code

[Ian Jackson]

Georg Faerber writes ("FHS: Where to store user specific plugins / code"):
> I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list
> manager with resending-capabilities".
> 
> Currently, we allow users to run / execute their own plugins, stored in
> /etc/schleuder/plugins. Obviously, that's not the right place, as /etc
> is for config files, not executable code. We would like to fix this, but
> are unsure which location to offer. The (empty) directory would be
> provided by the package, but the (possible) content would be provided by
> the user.
> 
> Therefore, I'm wondering what's the correct place: Would
> /usr/local/lib/schleuder/plugins be sensible? If not, any other place
> which is more suitable?

Do plugins do something which people might not want if present, and
not configured ?  If so then perhaps you want a thing a bit like the
apache mods-enabled scheme: a link farm.

If not, then if it's easy to do I would load all plugins in
/usr/local/lib/schleuder/plugins
/usr/lib/schleuder/plugins
(former masking the latter with for with the same name)

Ian.