profiles: qutebrowser: add passwd to private-etc

[amano-kenji]

Without those files in private-etc, qutebrowser cannot launch terminal emulators.

I personally think we shouldn't add individual files to private-etc. There should be file groups that we give to private-etc.

Like

private-etc @common,@3d,@audio,@dbus,@gui,@gtk,@kde,@networking,@qt

[kmk3]

@amano-kenji on Jan 27:

I personally think we shouldn't add individual files to private-etc. There
should be file groups that we give to private-etc.

Like

private-etc @common,@3d,@audio,@dbus,@gui,@gtk,@kde,@networking,@qt

Agreed; see #5610 and commit d1124df ("private-etc rework: /etc file groups",
2023-01-22).

[glitsj16]

Without those files in private-etc, qutebrowser cannot launch terminal emulators.

Terminal emulators have special status in Firejail profiles:

firejail/etc/inc/disable-common.inc

Lines 553 to 576 in b0822c0

	# prevent lxterminal connecting to an existing lxterminal session
	blacklist /tmp/.lxterminal-socket*
	# prevent tmux connecting to an existing session
	blacklist /tmp/tmux-*
	# disable terminals running as server resulting in sandbox escape
	blacklist ${PATH}/gnome-terminal
	blacklist ${PATH}/gnome-terminal.wrapper
	blacklist ${PATH}/kgx
	# blacklist ${PATH}/konsole
	# konsole doesn't seem to have this problem - last tested on Ubuntu 16.04
	blacklist ${PATH}/lilyterm
	blacklist ${PATH}/lxterminal
	blacklist ${PATH}/mate-terminal
	blacklist ${PATH}/mate-terminal.wrapper
	blacklist ${PATH}/pantheon-terminal
	blacklist ${PATH}/roxterm
	blacklist ${PATH}/roxterm-config
	blacklist ${PATH}/terminix
	blacklist ${PATH}/tilix
	blacklist ${PATH}/urxvtc
	blacklist ${PATH}/urxvtcd
	blacklist ${PATH}/xfce4-terminal
	blacklist ${PATH}/xfce4-terminal.wrapper

I don't fully understand which terminal emulators would actually benefit from these additional private-etc items when qutebrowser.profile includes disable-common.inc to block most of them in the first place. Am I missing something here?

[amano-kenji]

I configured qutebrowser to launch a text editor in a terminal emulator in response to config-edit command.

Somehow, terminal emulators required access to /etc/passwd. passwd and group are already in common private-etc group anyway.

After private-etc rework, those are going to be added anyway via @common.

Merging this doesn't break anything. Let's merge it quickly. We want to tie the loose ends as soon as possible and free our minds to do other things. If we have anything to discuss, let's open a discussion.

[glitsj16]

I configured qutebrowser to launch a text editor in a terminal emulator in response to config-edit command.

That's fine. Still, this could result in a sandbox escape. IMO it's a risky use case, hence not something we should allow without further details (like which text editor? in which terminal emulator?).

passwd and group are already in common private-etc group anyway

This is incorrect. Only passwd is currently, group is not. Check etc_groups.h.

Merging this doesn't break anything. Let's merge it quickly. We want to tie the loose ends as soon as possible and free our minds to do other things. If we have anything to discuss, let's open a discussion.

If there is anything besides a personal use case (a risky one IMO) that warrants merging this, I don't see it. Nor do I understand the rush to do so. No need to open a discussion thread, we're having a discussion right here.

[kmk3]

@amano-kenji on Jan 27:

Merging this doesn't break anything.

Neither does making the profile completely blank, though that does not seem
like a good idea.

Let's merge it quickly. We want to tie the loose ends as soon as possible and
free our minds to do other things.

I don't see any reason to rush this either. Also, the issues raised by
@glitsj16 sound like "looses ends" themselves, so if you are interested in
improving the profile, then feel free to help tie them.

[kmk3]

(Changing status to note that this is being discussed)

#5624 (comment)

[amano-kenji]

I'm fine with discussion as long as people respond. On some pull requests, there is not a response for weeks.

That's fine. Still, this could result in a sandbox escape. IMO it's a risky use case, hence not something we should allow without further details (like which text editor? in which terminal emulator?).

I use kakoune and neovim in alacritty terminal emulator. My experiment result is that I only need to add passwd to private-etc for terminal emulators to work in qutebrowser firejail.

config-edit command has to open an external editor, and I don't use a GUI editor. No GUI editor I know is nearly as good as neovim or kakoune. Not being able to open an editor by default is a bug. I use emacs, but it's not a good idea for external programs to use emacs as an external editor. Emacs is best used with emacs packages.

I think terminal editor usage would be quite common among advanced users who use qutebrowser and firejail. Who doesn't use terminal editors?

[amano-kenji]

I just updated the pull request. It now adds only passwd to private-etc.

[amano-kenji]

For a change, I replaced kakoune in a terminal emulator with nvim-qt which required those lines in firejail.

qutebrowser.local

# for nvim-qt support
include allow-nvim.inc
whitelist /usr/share/nvim
mkdir ${HOME}/.cache/nvim
mkdir ${HOME}/.config/nvim
mkdir ${HOME}/.local/share/nvim
mkdir ${HOME}/.local/state/nvim
whitelist ${HOME}/.cache/nvim
whitelist ${HOME}/.config/nvim
whitelist ${HOME}/.local/share/nvim
whitelist ${HOME}/.local/state/nvim

allow-nvim.inc

include allow-lua.inc
noblacklist ${HOME}/.cache/nvim
noblacklist ${HOME}/.config/nvim
noblacklist ${HOME}/.local/share/nvim
noblacklist ${HOME}/.local/state/nvim
ignore read-only ${HOME}/.config/nvim
ignore read-only ${HOME}/.local/share/nvim
ignore read-only ${HOME}/.local/state/nvim

[glitsj16]

LGTM

[kmk3]

@amano-kenji on Jan 28:

I'm fine with discussion as long as people respond. On some pull requests,
there is not a response for weeks.

This is a community Free Software project, which is maintained by a handful of
volunteers. You are free to copy and modify it, but you are not entitled to
anyone else's free time nor to have your changes incorporated upstream.

Additionally, there are not only pull requests, but also issues and discussions
that are constantly being opened and updated. And I'd wager that the majority
of them do get a response within a week, especially if the issue/proposal is
clear enough and sufficient details are provided. Note also that it is not
uncommon for the people that create issues/PRs/discussions themselves to not
reply for a long time, which results in the items remaining open indefinitely
(until/unless someone triages them).

If you want to see the response times reduced in general, then feel free to
help users in issues/discussions.

[kmk3]

@amano-kenji on Jan 28:

For a change, I replaced kakoune in a terminal emulator with nvim-qt which
required those lines in firejail.

allow-nvim.inc

include allow-lua.inc
noblacklist ${HOME}/.cache/nvim
noblacklist ${HOME}/.config/nvim
noblacklist ${HOME}/.local/share/nvim
noblacklist ${HOME}/.local/state/nvim
ignore read-only ${HOME}/.config/nvim
ignore read-only ${HOME}/.local/share/nvim
ignore read-only ${HOME}/.local/state/nvim

I'm not sure about the risks of allowing paths related to terminal emulators,
but I was working on an allow-text-editors.inc a long time ago, which contained
similar commands. The main issue was that whitelisting profiles also need
whitelisting commands in ${HOME} and possibly in ${RUNUSER}, both of which
may break profiles that do not do whitelisting in both of those paths.

The conclusion was that whitelisting commands need to be improved so that a
single include profile would be compatible with any includer. I have a big WIP
proposal written, but there is already the big private-etc rework going on and
Landlock support is queued up, so the improvements might have to wait.

[amano-kenji]

This is a community Free Software project, which is maintained by a handful of volunteers. You are free to copy and modify it, but you are not entitled to anyone else's free time nor to have your changes incorporated upstream.

Note also that it is not uncommon for the people that create issues/PRs/discussions themselves to not reply for a long time, which results in the items remaining open indefinitely (until/unless someone triages them).

I get only voluntary interactions are legitimate. However, if people are going to contribute, there are good ways and bad ways. We should definitely improve responsivenss and speed in most cases.

If a handful of voluntary maintainers are spread thin and don't have time to respond to pull requests and issues, then they should recruit more maintainers who actually have time. I think most projects don't even try to recruit more maintainers although they can't respond to pull requests for months at a time. At that point, it is more productive to fork and take over than to wait for them. After taking over, I would recruit maintainers if I don't have time to maintain it myself. You can be a manager without actually having to review issues and pull requests.

I think health and time/energy management are big. People who are unhealthy should improve sleep and food. People who are spread thin among many things should reduce the number of things they do intentionally. When it comes to productivity, less is more. You can achieve more by cutting things out. For example, if you make a lot of money, you can hire a chef to reduce the amount of time you spend on cooking and grocery shopping. If you don't, you can cook in big batches. It's important to cut things out if you want to achieve anything. I had enough time after cutting out entertainment and various unimportant pursuits.

Two things that can improve open source projects

1. Managers whose main responsibility is to recruit and manage maintainers. They may do some coding, but they mostly just delegate to other maintainers.
2. Productivity. Time management. Less is more. Cut things out. Sleep. Food. Exercise. Daily schedule.

[kmk3]

@amano-kenji on Jan 28:

I get only voluntary interactions are legitimate. However, if people are
going to contribute, there are good ways and bad ways. We should definitely
improve responsivenss and speed in most cases.

If a handful of voluntary maintainers are spread thin and don't have time to
respond to pull requests and issues, then they should recruit more
maintainers who actually have time. I think most projects don't even try to
recruit more maintainers although they can't respond to pull requests for
months at a time. At that point, it is more productive to fork and take over
than to wait for them. After taking over, I would recruit maintainers if I
don't have time to maintain it myself. You can be a manager without actually
having to review issues and pull requests.

Two things that can improve open source projects

1. Managers whose main responsibility is to recruit and manage maintainers.
   They may do some coding, but they mostly just delegate to other
   maintainers.

Usually a manager is someone that defines lists of things and priorities for
other people to work on (among other things). People might be willing to
follow those lists when they're being paid to do so. Otherwise, unless the
designated manager has already made substantial contributions to the project, I
find the idea unlikely to be helpful, especially on smaller projects.

And if there aren't that many people regularly triaging things anyway (even if
relatively a lot of it gets done), I don't see how adding more management would
help.

So if by "recruiting maintainers" you mean attracting people interested in
helping out in general (that is, regular contributors), that does seem like it
would be more of an improvement.

Though how to go about it would be the main question.

For example, I'm not sure if it would be a good idea to go around the internet
"recruiting" people, but maybe we could add a "help wanted" section in
README.md or something like that.

2. Productivity. Time management. Less is more. Cut things out. Sleep. Food.
   Exercise. Daily schedule.

I think health and time/energy management are big. People who are unhealthy
should improve sleep and food. People who are spread thin among many things
should reduce the number of things they do intentionally. When it comes to
productivity, less is more. You can achieve more by cutting things out. For
example, if you make a lot of money, you can hire a chef to reduce the amount
of time you spend on cooking and grocery shopping. If you don't, you can cook
in big batches. It's important to cut things out if you want to achieve
anything. I had enough time after cutting out entertainment and various
unimportant pursuits.

Those sound generally like reasonable things to try (in fact, I'd vouch for
some of them) and I appreciate the attempt to help in this particular instance.
But I think that they are outside the scope of what is done on software forges.
That is, I don't think I'd go around giving life advice unprompted on software
projects (especially with the expectation that it would lead to increased
contributions on a given project), even if I consider the advice itself to be
useful, as people might take this the wrong way and/or the
implementation/results might end up being very different than intended (for
example, with regards to improving the food aspect). Though it might make
sense in a longer form (like in a blog post).

Also, note that even if maintainers have a good life balance, the user requests
may still outpace the dedicated time and energy. And in fact, improving the
balance could very well mean reducing contributions in favor of something else.

[amano-kenji]

So if by "recruiting maintainers" you mean attracting people interested in helping out in general (that is, regular contributors), that does seem like it would be more of an improvement.

Recruiting maintainers means asking contributors to become maintainers if the manager thinks the project is not getting enough attention. Contributors who submit pull requests are the best candidates for new maintainers.

netblue30 is a manager of some sort.

Linus Torvalds is also a manager of some sort. He writes some linux code, but much of the linux code comes from other people.

There are many different styles of management. The style of management I suggest would be just to ask contributors to become maintainers and demote those who "unnecessarily" slow down pull requests for months or verbally attack others or often break existing users carelessly. This purpose of this kind of management is to make sure that issues and pull requests get enough attention by anyone who can.

Maintainers of projects that stagnate don't ask contributors to become maintainers and don't have time to pay attention to issues and pull requests. netblue30 was wise enough to promote contributors to maintainers. This project is getting attention. Promoting contributors if there should be more attention should not take much time from the manager.

This style of management seems good for small projects which struggle to get attention. My analysis is that the bottleneck in most cases is not lack of attention but refusal to promote contributors to maintainers even though the managers have no time to pay attention to their projects. They intentionally or subconsciously refuse more attention because they don't trust other people and they don't really care.

Care and attention are the most important resources in the universe. With enough care and attention, anything seems possible, given enough time.