Re: FHS: Where to store user specific plugins / code
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
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
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
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
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
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
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 <https://theos.kyriasis.com/~kyrias/basedir-spec.html>, 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
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 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
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
On Wed, 28 Feb 2018 09:54:14 -0800 Georg Faerberwrote 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
* 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
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.
FHS: Where to store user specific plugins / code
Hi Debian Developers, all, 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? Looking forward to your input! All the best, cheers, Georg [1] https://tracker.debian.org/pkg/schleuder signature.asc Description: Digital signature