[SOLVED] Re: [gentoo-user] jupyter notebook 500 : Internal Server Error
On 6/26/20 10:08 AM, Andreas K. Huettel wrote: Am Donnerstag, 25. Juni 2020, 22:13:46 CEST schrieb Valmor de Almeida: Hello, I had to enable ~amd64 to emerge jupyter so I know this is bound for problems. However, anyone there able to use jupyter notebooks in gentoo? No matter what notebook I try to open, I get the internal server error. Thank you. Try updating dev-python/nbconvert to a version newer than the stable one. You probably did this the same way as me, keywording only what was really necessary on an otherwise stable system. Problem is, notebooks have an internal versioning, and nbconvert-5.2 doesn't support recent versions anymore. After updating nbconvert things worked fine for me. (Time to fix this, I know, but there's only so many hours in the day...) Thank you. It worked! -- Vamor Here is some info for reference: * dev-python/jupyter Latest version available: 1.0.0-r2 Latest version installed: 1.0.0-r2 Size of files: 15 KiB Homepage: https://jupyter.org Description: Jupyter metapackage. Install all the Jupyter components in one go License: BSD * dev-python/jupyter_client Latest version available: 5.2.3-r1 Latest version installed: 5.2.3-r1 Size of files: 266 KiB Homepage: https://jupyter.org Description: Jupyter protocol implementation and client libraries License: BSD * dev-python/jupyter_console Latest version available: 6.1.0 Latest version installed: 6.1.0 Size of files: 28 KiB Homepage: https://jupyter.org Description: A terminal-based console frontend for Jupyter kernels License: BSD * dev-python/jupyter_core Latest version available: 4.6.1-r1 Latest version installed: 4.6.1-r1 Size of files: 66 KiB Homepage: https://jupyter.org Description: Core common functionality of Jupyter projects License: BSD * dev-python/nbconvert Latest version available: 5.6.1 Latest version installed: 5.5.0 Size of files: 687 KiB Homepage: https://nbconvert.readthedocs.io/ Description: Converting Jupyter Notebooks License: BSD /etc/portage/package.accept_keywords/jupyter dev-python/jupyter ~amd64 dev-python/jupyter_console ~amd64 dev-python/nbconvert ~amd64 /etc/portage/package.use/jupyter net-libs/zeromq drafts dev-python/PyQt5 gui svg widgets x11-libs/libxkbcommon X dev-libs/libpcre pcre16 dev-libs/libpcre2 pcre16 emerge jupyter emerge =nbconvert-5.5.0
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On Sat, Jun 27, 2020, at 5:43 AM, Rich Freeman wrote: > But, as I said, using more uids/gids in general means having more > separation. In general it only increases security, with the caveat > that it does potentially make auditing more complex. > Android's security model is uid per app. This is about as effective you can get on a mostly stock kernel. There is essentially no isolation within a uid. It's also why it is very hard to use an Android phone for anything without rooting it. If you look at the CVEs for Android they are typically rather benign, the more persistent issue is you constantly carry the device with you.
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On Fri, Jun 26, 2020 at 10:18 PM james wrote:
>
> On 6/26/20 4:40 PM, Rich Freeman wrote:
> > Removing the group doesn't actually make things more secure, because
> > processes can use a gid even if it doesn't exist in /etc/groups.
> > Effectively any POSIX system has every uid/gid available even if there
> > is no /etc/passwd at all.
>
> And that is coded into the parts of the kernel, we cannot eliminate?
> Typical sploits?
>
> Curiously, a bit deeper explanation?
So, ultimately a uid/gid is just a number, and a field in a couple of
tables. Inodes have them, and processes have them. There might be
other things that have them that I'm not thinking of, but those are
probably the main two.
If a process wants to send signals to another process the uids have to
match, or it must have a capability to break this rule. If a process
wants to read a file, the uid/gid/permissions/ACLs/etc must correspond
appropriately. I'm sure there are a bunch of other system calls where
uids/gids matter as well.
The field that stores the IDs has a certain size, and thus any number
within the expressible range is valid. You can't "get rid" of a UID
any more than you can ban the number 13. However, since the logic is
based on matching it really doesn't matter much - if you launch a
process with a UID you intended to be "unused" it basically is
completely isolated as far as the filesystem and other processes go
since its UID doesn't match anything else (it could still touch world
read/writeable files, but that is true if it ran under a UID you
preferred that it use).
The files /etc/passwd and /etc/group are used by various system
programs to map these IDs to human-readable names, but they really
aren't part of how the kernel works. Just about any command that can
take a username can take a user ID, and if you want to really drive
people crazy go ahead and try using numeric usernames (I believe the
IDs take precedence in command lines).
So, if you deleted /etc/{passwd,group,shadow} you could still have a
"perfectly working" linux userspace, but commands like login wouldn't
work as those use usernames and of course there would be no mapping to
passwords. However init would still run as uid 0, and it could launch
processes with other uids, and those processes would have regular
filesystem behavior. It wouldn't be POSIX and various things might
break, but you could have a name-less userspace just fine on linux.
The kernel itself never looks at /etc/shadow and so on - it just sees
numeric IDs. Android is an example of an OS that makes some
substantial changes in userspace to how things like UIDs are
traditionally used (that, and the OOM killer).
Most things associated with users/groups in linux are conventions
implemented in userspace.
But, as I said, using more uids/gids in general means having more
separation. In general it only increases security, with the caveat
that it does potentially make auditing more complex.
--
Rich
