Re: [gentoo-dev] dynamic groups and users
On Thu, 2019-08-01 at 21:04 +0200, Jaco Kroon wrote:
> Hi,
>
> Looking at the new eclasses for acct-user and acct-group.
>
> These enforce that a group and user id should be set.
>
> This is not a requirement for enewuser nor enewgroup.
>
> As a further discrepancy, the user eclass requires >0 for the IDs,
> whereas the checks in acct-user and acct-group is for >= 0.
>
> Would it be ok to suggest that we allow -1 (or 0, but that could be
> confused with the root user/group) in acct-user and acct-group to
> specify "no specific id, please allocate dynamically"?
>
> Use case: I'm building some experimental packages in an overlay, and I
> really don't care what the UID and GID values are, I just need something
> unique on the host I can use to avoid running the service as root.
> Guessing I could just manually useradd -r but then again ... if I do
> later submit these into the main tree (or other packages) then it
> becomes a problem, and maintaining acct-{user,group}/* outside of main
> tree could conflict with main tree at a later stage ... either way,
> having some way to say "I honestly don't care, just give me a random
> number" is probably a good thing.
>
I'll look into adding support for '-1' in a few days. However, I'm
going to add QA checks to prevent it from getting into ::gentoo first.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-p2p/multibit
# Michał Górny (01 Aug 2019) # Discontinued upstream in July 2017. Has irritating bugs, and is hard # to build from source (we have binary package only). Upstream # recommends net-misc/electrum as a replacement. # See: https://multibit.org/blog/2017/07/26/multibit-shutdown.html # Removal in 30 days. Bug #639530. net-p2p/multibit -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] dynamic groups and users
Hi,
Looking at the new eclasses for acct-user and acct-group.
These enforce that a group and user id should be set.
This is not a requirement for enewuser nor enewgroup.
As a further discrepancy, the user eclass requires >0 for the IDs,
whereas the checks in acct-user and acct-group is for >= 0.
Would it be ok to suggest that we allow -1 (or 0, but that could be
confused with the root user/group) in acct-user and acct-group to
specify "no specific id, please allocate dynamically"?
Use case: I'm building some experimental packages in an overlay, and I
really don't care what the UID and GID values are, I just need something
unique on the host I can use to avoid running the service as root.
Guessing I could just manually useradd -r but then again ... if I do
later submit these into the main tree (or other packages) then it
becomes a problem, and maintaining acct-{user,group}/* outside of main
tree could conflict with main tree at a later stage ... either way,
having some way to say "I honestly don't care, just give me a random
number" is probably a good thing.
Kind Regards,
Jaco
Re: [gentoo-dev] dynamic groups and users
On Thu, Aug 1, 2019 at 3:04 PM Jaco Kroon wrote:
>
> Hi,
>
> Looking at the new eclasses for acct-user and acct-group.
>
> These enforce that a group and user id should be set.
>
> This is not a requirement for enewuser nor enewgroup.
The new eclasses require you to set a fixed id, but they do not
enforce that the id is available by default. If the id is taken
already, it will allocate a new one.
User/group 0 is pretty much guaranteed to always exist, so you could
set ACCT_{GROUP,USER}_ID=0 to trigger the desired behavior.
If you're feeling crazy, this will get you a random assignment between
1 and 999, with the same fallback logic.
ACCT_GROUP_ID=$(( RANDOM % 998 + 1 ))
Re: [gentoo-dev] dynamic groups and users
Hi Mike,
From user.eclass:
146 if [[ ${euid} -gt 0 ]] ; then
147 if [[ -n $(egetent passwd ${euid}) ]] ; then
148 [[ -n ${force_uid} ]] && die "${FUNCNAME}: UID
${euid} already taken"
149 euid="next"
150 fi
151 else
152 eerror "Userid given but is not greater than 0 !"
153 die "${euid} is not a valid UID"
154 fi
Similar for egid.
This is the discrepency of >=0 (acct-user and acct-group) vs >0 (user) I
was referring. So yes, I can set it, but the underlying enewuser and
enewgroup calls is going to kick out as per above.
Yes, I could use something like uid=1 (bin) and gid=1 (bin) which I'm
reasonably sure use comes from baselayout and is thus almost guaranteed
to conflict always, but the *intention* of that's unclear. I'd rather
(and I'm happy to write the patches, just don't want to waste my time
doing so if it's of no interest to anyone else) have a way to explicitly
state "I really don't care about this uid or gid value". Also, should
it be required to be set to eg -1 to indicate this, or is the variable
not being set a good enough indication? I'm included to require -1 else
a simple typo could result in accidental dynamic allocation.
Regarding your $RANDOM idea ... that is rather crazy, and will work,
however, I suspect you should make that % 499 ... saw an email earlier
about the IDs should be <500 since 500 to 999 is reserved for dynamic
allocation.
I currently have at least four dynamically allocated groups on the
machine I'm typing this on:
tcpdump:x:999:
mrtg:x:998:
rrd:x:997:
ulsreport:x:996:
I like the idea of it being allocated from 999 downwards, and I really
think dynamic allocation makes sense for many packages. I do support
the idea of predictable IDs, for packages which can trivially use shared
storage (eg, mail). For other packages (eg, webrtc2sip which I'm
working with currently) it seriously doesn't matter as it'll never write
to disk (other than the log files ...). Heck, even if it could, sharing
that state wouldn't make much sense either. Even something like
asterisk being predictable makes sense, since
/var/spool/asterisk/monitor (and a few others, as we currently are)
could be shared between multiple hosts.
Kind Regards,
Jaco Kroon
On 2019/08/01 22:01, Mike Gilbert wrote:
On Thu, Aug 1, 2019 at 3:04 PM Jaco Kroon wrote:
Hi,
Looking at the new eclasses for acct-user and acct-group.
These enforce that a group and user id should be set.
This is not a requirement for enewuser nor enewgroup.
The new eclasses require you to set a fixed id, but they do not
enforce that the id is available by default. If the id is taken
already, it will allocate a new one.
User/group 0 is pretty much guaranteed to always exist, so you could
set ACCT_{GROUP,USER}_ID=0 to trigger the desired behavior.
If you're feeling crazy, this will get you a random assignment between
1 and 999, with the same fallback logic.
ACCT_GROUP_ID=$(( RANDOM % 998 + 1 ))
[gentoo-dev] Last rites: dev-games/vamos
# David Seifert (2019-08-01) # Dead upstream, last release over 5 years ago, # broken build system, fails with boost 1.70, # removal in 30 days. Bug #646014, #691162 dev-games/vamos
[gentoo-dev] Last rites: dev-python/pgmagick
# David Seifert (2019-08-01) # Last touched over 3 years ago, broken tests, # fails with boost 1.70, removal in 30 days. # Bug #655886, #690704
Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 31 Jul 2019 21:40:19 +0100 James Le Cuirot wrote: > On Wed, 31 Jul 2019 15:51:58 +0200 > Alexis Ballier wrote: > > > On Tue, 30 Jul 2019 23:26:27 +0100 > > James Le Cuirot wrote: > > > > > > Admittedly without a full understanding of the problem, but this > > > > looks wrong to me: SYSROOT, EPREFIX and BROOT are only relevant > > > > in build phases (src_*); (EPREFIX is a little special here but > > > > mostly for convenience). ROOT is only relevant in pkg_* phases. > > > > I don't see how this can work. Say I build a binpkg with ROOT=/ > > > > then use that binpkg with ROOT=/somewhere, you can't go back > > > > and change SYSROOT. > > > > > > ROOT is used to determine ESYSROOT, not the other way around. As > > > you say, (E)SYSROOT is only relevant in src phases so it doesn't > > > matter if ROOT has changed when installing a binpkg. > > > > I am missing something here: You are making ESYSROOT depend on the > > value of ROOT, so how can it not matter ? > > What I am trying to say (somewhat unsuccessfully!) is that the value > of (E)SYSROOT only changes how the package is built, not what the > resulting package looks like. It's where all the headers and libraries > are sourced from at build time, which is irrelevant at runtime. err, SYSROOT does change what the resulting package looks like: it defines ABI (headers and needed entries for example). > So why does ROOT affect it? Normally you install the packages for > BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and > RDEPEND are installed to different locations (ROOT!=/) then DEPEND > will almost always be installed to one of the other two. If either of > those two locations is prefixed then we need the prefix for DEPEND's > location to match, otherwise it wouldn't actually be the same > location. Using ROOT allows us to figure this out automatically in a > way that covers all sensible use cases and avoids accidentally > falling into an unsupported case. So, now let's simplify this a bit and forget about prefix and crossdev for a moment. Say I am building an atom chroot (for nfs root) on an haswell desktop. I set ROOT=SYSROOT=/atomchroot. My desktop has CFLAGS for haswell, and I have atom CFLAGS in /atomchroot/etc/portage/make.conf. When I build something and portage installs a BDEPEND to /, I want it to use my / configuration, and when it is in /atomchroot I want it to use the configuration from there. emerge has command line options to do that but I am not sure if this is properly specified in PMS. Now, say I am doing the same on a prefix haswell desktop. With your algorithm, we have SYSROOT==ROOT so ESYSROOT is EPREFIX/SYSROOT. However, what I want is a normal chroot with EPREFIX=/ here, so when should one use ESYSROOT in an ebuild in that case ? where does this EPREFIX comes from by the way ? To me, this looks more of a general problem of defining where the configuration is taken from, so that we can set EPREFIX independently if it is SYSROOT or BROOT. > I hope that's clearer. Sorry :-( -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXUL2ygAKCRAOJUi7xgfl rkwRAP9LDImZBCYxsWKMjT/ckCeK0hOLtctdpZuBwzjv5RIuiAD/cTUj7P7h9rBd gYaEEI+pqdN25ZNbjao/8w/j7SsXUMo= =WYef -END PGP SIGNATURE-
[gentoo-portage-dev] [PATCH v2] Configure additional addresses on the lo interface for network-sandbox
This works around some strange behavior in glibc's getaddrinfo()
implementation when the AI_ADDRCONFIG flag is set.
For example:
struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags =
AI_ADDRCONFIG };
getaddrinfo("localhost", NULL, , );
This returns no results if there are no non-loopback addresses configured.
Bug: https://bugs.gentoo.org/690758
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
Signed-off-by: Mike Gilbert
---
lib/portage/process.py | 50 +++---
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/lib/portage/process.py b/lib/portage/process.py
index dfbda75de..77f7fac02 100644
--- a/lib/portage/process.py
+++ b/lib/portage/process.py
@@ -446,6 +446,42 @@ def spawn(mycommand, env=None, opt_name=None,
fd_pipes=None, returnpid=False,
# Everything succeeded
return 0
+def _configure_loopback_interface():
+ """
+ Configure the loopback interface.
+ """
+
+ IFF_UP = 0x1
+ ifreq = struct.pack('16sh', b'lo', IFF_UP)
+ SIOCSIFFLAGS = 0x8914
+
+ sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
+ try:
+ fcntl.ioctl(sock, SIOCSIFFLAGS, ifreq)
+ except IOError as e:
+ writemsg("Unable to enable loopback interface: %s\n" %
e.strerror, noiselevel=-1)
+ sock.close()
+
+ # We add some additional addresses to work around odd behavior in
glibc's
+ # getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
+ #
+ # For example:
+ #
+ # struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags =
AI_ADDRCONFIG };
+ # getaddrinfo("localhost", NULL, , );
+ #
+ # This returns no results if there are no non-loopback addresses
+ # configured for a given address family.
+ #
+ # Bug: https://bugs.gentoo.org/690758
+ # Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
+
+ try:
+ subprocess.call(['ip', 'address', 'add', '10.0.0.1/8', 'dev',
'lo'])
+ subprocess.call(['ip', 'address', 'add', 'fd00::1/8', 'dev',
'lo'])
+ except OSError as e:
+ writemsg("Error calling 'ip': %s\n" % e.strerror, noiselevel=-1)
+
def _exec(binary, mycommand, opt_name, fd_pipes,
env, gid, groups, uid, umask, cwd,
pre_exec, close_fds, unshare_net, unshare_ipc, unshare_mount,
unshare_pid,
@@ -624,19 +660,7 @@ def _exec(binary, mycommand, opt_name, fd_pipes,
noiselevel=-1)
os._exit(1)
if unshare_net:
- # 'up' the loopback
- IFF_UP = 0x1
- ifreq =
struct.pack('16sh', b'lo', IFF_UP)
- SIOCSIFFLAGS = 0x8914
-
- sock =
socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
- try:
-
fcntl.ioctl(sock, SIOCSIFFLAGS, ifreq)
- except IOError as e:
-
writemsg("Unable to enable loopback interface: %s\n" % (
-
errno.errorcode.get(e.errno, '?')),
-
noiselevel=-1)
- sock.close()
+
_configure_loopback_interface()
except AttributeError:
# unshare() not supported by libc
pass
--
2.22.0
Re: [gentoo-portage-dev] [PATCH v2] Configure additional addresses on the lo interface for network-sandbox
On 8/1/19 6:22 AM, Mike Gilbert wrote:
> This works around some strange behavior in glibc's getaddrinfo()
> implementation when the AI_ADDRCONFIG flag is set.
>
> For example:
>
> struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags =
> AI_ADDRCONFIG };
> getaddrinfo("localhost", NULL, , );
>
> This returns no results if there are no non-loopback addresses configured.
>
> Bug: https://bugs.gentoo.org/690758
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
> Signed-off-by: Mike Gilbert
> ---
> lib/portage/process.py | 50 +++---
> 1 file changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/lib/portage/process.py b/lib/portage/process.py
> index dfbda75de..77f7fac02 100644
> --- a/lib/portage/process.py
> +++ b/lib/portage/process.py
> @@ -446,6 +446,42 @@ def spawn(mycommand, env=None, opt_name=None,
> fd_pipes=None, returnpid=False,
> # Everything succeeded
> return 0
>
> +def _configure_loopback_interface():
> + """
> + Configure the loopback interface.
> + """
> +
> + IFF_UP = 0x1
> + ifreq = struct.pack('16sh', b'lo', IFF_UP)
> + SIOCSIFFLAGS = 0x8914
> +
> + sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
> + try:
> + fcntl.ioctl(sock, SIOCSIFFLAGS, ifreq)
> + except IOError as e:
> + writemsg("Unable to enable loopback interface: %s\n" %
> e.strerror, noiselevel=-1)
> + sock.close()
> +
> + # We add some additional addresses to work around odd behavior in
> glibc's
> + # getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
> + #
> + # For example:
> + #
> + # struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags =
> AI_ADDRCONFIG };
> + # getaddrinfo("localhost", NULL, , );
> + #
> + # This returns no results if there are no non-loopback addresses
> + # configured for a given address family.
> + #
> + # Bug: https://bugs.gentoo.org/690758
> + # Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
> +
> + try:
> + subprocess.call(['ip', 'address', 'add', '10.0.0.1/8', 'dev',
> 'lo'])
> + subprocess.call(['ip', 'address', 'add', 'fd00::1/8', 'dev',
> 'lo'])
> + except OSError as e:
> + writemsg("Error calling 'ip': %s\n" % e.strerror, noiselevel=-1)
> +
> def _exec(binary, mycommand, opt_name, fd_pipes,
> env, gid, groups, uid, umask, cwd,
> pre_exec, close_fds, unshare_net, unshare_ipc, unshare_mount,
> unshare_pid,
> @@ -624,19 +660,7 @@ def _exec(binary, mycommand, opt_name, fd_pipes,
>
> noiselevel=-1)
> os._exit(1)
> if unshare_net:
> - # 'up' the loopback
> - IFF_UP = 0x1
> - ifreq =
> struct.pack('16sh', b'lo', IFF_UP)
> - SIOCSIFFLAGS = 0x8914
> -
> - sock =
> socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
> - try:
> -
> fcntl.ioctl(sock, SIOCSIFFLAGS, ifreq)
> - except IOError as e:
> -
> writemsg("Unable to enable loopback interface: %s\n" % (
> -
> errno.errorcode.get(e.errno, '?')),
> -
> noiselevel=-1)
> - sock.close()
> +
> _configure_loopback_interface()
> except AttributeError:
> # unshare() not supported by libc
> pass
>
Looks good. Please merge.
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
