from:"Blaisorblade"

[Touch-packages] [Bug 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2017-03-15 Thread Blaisorblade

Replying to #35:
> So, I'm downgrading this from critical to high since it only hits users of 
> 16.10 server in a few corner cases (i.e. containers, chroots without 
> libnss-resolve installed). It should still be SRUed.

Another corner case seems to be binaries linked against musl libc, since
they do not use NSS.

We're getting many reports related the problem on the Haskell stack tool
(https://github.com/commercialhaskell/stack/issues/2536#issuecomment-285327722),
and we indeed link against musl libc
(https://github.com/commercialhaskell/stack/issues/3060).

To be sure, is the plan to make the local DNS proxy at least resolve
CNAME correctly on Yakkety and future releases, either by fixing systemd
or switching to dnsmasq? Only providing `libnss-resolve` is not enough.
I'm not aware of us needing fancier DNS features, but correct CNAME
support would be great.

I understand you don't include musl libc, but except for this bug it's
an attractive option for shipping one universal Linux binary, which I
suggest Ubuntu should keep supporting. Since the bug affects other
scenarios anyway, I think it's reasonable to hope for a fix. I
appreciate your effort.

** Bug watch added: github.com/commercialhaskell/stack/issues #2536
   https://github.com/commercialhaskell/stack/issues/2536

** Bug watch added: github.com/commercialhaskell/stack/issues #3060
   https://github.com/commercialhaskell/stack/issues/3060

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1647031

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in Nextcloud:
  Unknown
Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in network-manager source package in Yakkety:
  Invalid
Status in systemd source package in Yakkety:
  Triaged

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nextcloud-snap/+bug/1647031/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1321854] Re: useradd doesn't add the default shell to /etc/passwd entry

2015-09-16 Thread Blaisorblade

I found a possible culprit. Patch debian/patches/1000_configure_userns
swaps the order of `get_defaults`* and `process_flags`, but it's the job
of `process_flags` to read the defaults if they weren't overridden on
the command line. For instance, `process_flags` contains

```
if (!gflg) {
user_gid = def_group;
}

if (!sflg) {
user_shell = def_shell;
}
```

In fact, `process_flags` will end up doing that, but with the compiled-
in defaults. I'm not 100% sure I understand the patched code, but
***maybe*** the fix is as simple as restoring the order of instructions,
including of `is_sub_gid`; but I haven't read the logic for
`is_sub_gid`.

Here's the guilty patch fragment (not applicable):
```
--- shadow.orig/src/useradd.c   2014-02-16 19:31:38.934898148 -0500
+++ shadow/src/useradd.c2014-02-16 19:31:38.926898149 -0500
[...]
-
-   get_defaults ();

process_flags (argc, argv);

+   is_sub_uid = sub_uid_file_present () && !rflg &&
+   (!user_id || (user_id <= uid_max && user_id >= uid_min));
+   is_sub_gid = sub_gid_file_present () && !rflg &&
+   (!user_id || (user_id <= uid_max && user_id >= uid_min));
+
+   get_defaults ();
+
```

*I'm using Markdown syntax to distinguish code and text.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1321854

Title:
  useradd doesn't add the default shell to /etc/passwd entry

Status in shadow package in Ubuntu:
  Triaged
Status in shadow source package in Trusty:
  Triaged

Bug description:
  useradd is not honoring the default shell listed in
  /etc/defaults/useradd when creating new users.

  useradd -D showing the defaults. SHELL=/bin/bash

  # useradd -D
  GROUP=100
  HOME=/home
  INACTIVE=-1
  EXPIRE=
  SHELL=/bin/bash
  SKEL=/etc/skel
  CREATE_MAIL_SPOOL=no

  Using useradd to create user test1. The /etc/passwd entry has a blank
  shell field:

  # useradd test1
  # grep test1 /etc/passwd
  test1:x:2080:2080::/home/test1:

  Using useradd -s does populate the shell field:
  # useradd -s /bin/bash test2
  #grep test2 /etc/passwd
  test2:x:2081:2081::/home/test2:/bin/bash

  Why useradd instead of adduser: puppet uses useradd to do user
  creation.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: passwd 1:4.1.5.1-1ubuntu9
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  Date: Wed May 21 17:51:57 2014
  Ec2AMI: ami-42dc302a
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: us-east-1d
  Ec2InstanceType: m3.large
  Ec2Kernel: aki-919dcaf8
  Ec2Ramdisk: unavailable
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: shadow
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.useradd: 2014-05-21T17:36:05.208686

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1321854/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1321854] Re: useradd doesn't add the default shell to /etc/passwd entry

2015-09-16 Thread Blaisorblade

Sorry, I shouldn't have made the previous comment — I had just looked at
the last comment. Now I looked at the rest of the code, and discovered
that you have already a fix, you just didn't apply it to trusty. Would
you please do so?

Roberto (#7), you are correct, but IIUC that *is* addressed by the patch
for utopic.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1321854

Title:
  useradd doesn't add the default shell to /etc/passwd entry

Status in shadow package in Ubuntu:
  Triaged
Status in shadow source package in Trusty:
  Triaged

Bug description:
  useradd is not honoring the default shell listed in
  /etc/defaults/useradd when creating new users.

  useradd -D showing the defaults. SHELL=/bin/bash

  # useradd -D
  GROUP=100
  HOME=/home
  INACTIVE=-1
  EXPIRE=
  SHELL=/bin/bash
  SKEL=/etc/skel
  CREATE_MAIL_SPOOL=no

  Using useradd to create user test1. The /etc/passwd entry has a blank
  shell field:

  # useradd test1
  # grep test1 /etc/passwd
  test1:x:2080:2080::/home/test1:

  Using useradd -s does populate the shell field:
  # useradd -s /bin/bash test2
  #grep test2 /etc/passwd
  test2:x:2081:2081::/home/test2:/bin/bash

  Why useradd instead of adduser: puppet uses useradd to do user
  creation.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: passwd 1:4.1.5.1-1ubuntu9
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  Date: Wed May 21 17:51:57 2014
  Ec2AMI: ami-42dc302a
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: us-east-1d
  Ec2InstanceType: m3.large
  Ec2Kernel: aki-919dcaf8
  Ec2Ramdisk: unavailable
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: shadow
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.useradd: 2014-05-21T17:36:05.208686

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1321854/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

[Touch-packages] [Bug 1321854] Re: useradd doesn't add the default shell to /etc/passwd entry

[Touch-packages] [Bug 1321854] Re: useradd doesn't add the default shell to /etc/passwd entry

3 matches

Site Navigation

Mail list logo

Footer information