Re: how sudo handles $HOME
On Tue, May 14, 2019 at 01:12:56PM -0400, Dan Streetman wrote: > in Ubuntu, sudo retains the calling user's $HOME > > this is different from upstream sudo as well as all other UNIXes and > even the sudo documentation we provide. Should we remove our custom > patch that adds this behavior? Does upstream have a position on this question, apart from our observation of their current default? For example: what if we changed it back, then someone persuaded upstream to flip the default? That would cause disruption to our users twice. Can we ensure, before reverting to their default, that upstream have no intention of changing it? Robie signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: how sudo handles $HOME
On 5/16/19 3:03 AM, Alex Murray wrote: On Wed, 2019-05-15 at 02:42:56 +0930, Dan Streetman wrote: in Ubuntu, sudo retains the calling user's $HOME this is different from upstream sudo as well as all other UNIXes and even the sudo documentation we provide. Should we remove our custom patch that adds this behavior? I would argue that our current behaviour provides a more usable default (eg. running vim via sudo uses your own configuration so you don't have to maintain a copy of it in /root) and in the case of a machine with multiple sudo users, they all get to use their own configuration rather than a single configuration under /root. However, it does diverge from upstream and so for new users this creates a surprising situation if they are used to and expect the upstream behaviour - (see comments 6 and 7 in https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/760140) - plus it seems we do not document this change in the man page and so we are creating even more surprises for our users. From a security point of view I do not see any advantage from either behaviour, so it is really more a usability question IMO. for reference and more details on downsides of our current sudo behavior, see: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302 Note that I have kind-of hijacked the bug, as I believe the issue is larger than the python-based example in that bug. Also as I commented in that bug, I do not recommend changing the behavior for existing releases. But I do think we should change the behavior starting in Eoan and future releases. I agree if this is changed we should not try and SRU it back. I would say let it remain user's home for editor configs. You could always use option -i in case you want root home. -- -=oOOo=- Carl Friis-Hansen https://carl-fh.com/ https://dronehyr.se/ Phone: +46 372 775199 -=oOOo=- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: how sudo handles $HOME
Good question. I've cc'ed sudo-users, so the question to the upstream sudo list can be summarized as: How likely would it be for upstream sudo to add HOME to env_keep by default? We ask because Ubuntu carries a patch that adds HOME to env_keep, unlike the default upstream, or any other Linux/Unix. We are considering removing that patch, to match upstream defaults, of *not* including HOME in env_keep. More details are in this bug: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302 On Thu, May 16, 2019 at 5:10 AM Robie Basak wrote: > > On Tue, May 14, 2019 at 01:12:56PM -0400, Dan Streetman wrote: > > in Ubuntu, sudo retains the calling user's $HOME > > > > this is different from upstream sudo as well as all other UNIXes and > > even the sudo documentation we provide. Should we remove our custom > > patch that adds this behavior? > > Does upstream have a position on this question, apart from our > observation of their current default? > > For example: what if we changed it back, then someone persuaded upstream > to flip the default? That would cause disruption to our users twice. Can > we ensure, before reverting to their default, that upstream have no > intention of changing it? > > Robie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: how sudo handles $HOME
On Thu, May 16, 2019 at 6:35 AM Carl Friis-Hansen wrote: > > On 5/16/19 3:03 AM, Alex Murray wrote: > > > > On Wed, 2019-05-15 at 02:42:56 +0930, Dan Streetman wrote: > > > >> in Ubuntu, sudo retains the calling user's $HOME > >> > >> this is different from upstream sudo as well as all other UNIXes and > >> even the sudo documentation we provide. Should we remove our custom > >> patch that adds this behavior? > > > > I would argue that our current behaviour provides a more usable default > > (eg. running vim via sudo uses your own configuration so you don't have > > to maintain a copy of it in /root) and in the case of a machine with > > multiple sudo users, they all get to use their own configuration rather > > than a single configuration under /root. > > > > However, it does diverge from upstream and so for new users this creates > > a surprising situation if they are used to and expect the upstream > > behaviour - (see comments 6 and 7 in > > https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/760140) - plus it > > seems we do not document this change in the man page and so we are > > creating even more surprises for our users. > > > > From a security point of view I do not see any advantage from either > > behaviour, so it is really more a usability question IMO. > > > >> > >> for reference and more details on downsides of our current sudo behavior, > >> see: > >> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302 > >> > >> Note that I have kind-of hijacked the bug, as I believe the issue is > >> larger than the python-based example in that bug. > >> > >> Also as I commented in that bug, I do not recommend changing the > >> behavior for existing releases. But I do think we should change the > >> behavior starting in Eoan and future releases. > > > > I agree if this is changed we should not try and SRU it back. > > > I would say let it remain user's home for editor configs. > You could always use option -i in case you want root home. That is a significant upside to current behavior; but please don't forget about the downside of accessing editor configs under sudo: root-owned editor config files, e.g.: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302/comments/9 For some users, this is a simple fix of running sudo chown. For users simply following online directions though, the errors resulting from this can be quite frustrating and confusing. Try googling for 'root owned emacs.d' or 'root owned viminfo', e.g.: http://blog.robertelder.org/vim-forgets-copy-buffer-on-reopen/ For those that commonly use fresh vms or containers, root-owned editor config files can be a common occurance/annoyance. > > -- >-=oOOo=- > Carl Friis-Hansen > https://carl-fh.com/ > https://dronehyr.se/ > Phone: +46 372 775199 >-=oOOo=- > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
apache2 package and continued Certbot compatibility
Hello, The following message is intended for the maintainers of the apache2 package: We’re maintaining Certbot and it’s Apache plugin on Ubuntu. In the past, changes to the Apache HTTPd package on different OSes have broken the way Certbot interacts with web server. We are contacting to let you know what functionality we are relying on to see if we can find a way to ensure uninterrupted operability of Certbot on Ubuntu. We would also love to hear your thoughts about the way we’re currently doing this - especially if you think there would be a better practice to do some or all of these actions on Ubuntu. If possible, we would also like to get notified if some of the functionality of these interaction points that we depend on changes, so we can adapt our code before the functionality breaks for the users. If your distribution’s packaging infrastructure allows tests that could send notifications over to us, it would be a great thing to have. That said, we definitely do not want to block your development or maintenance of Apache HTTPd on Ubuntu, but would merely like to keep our software compatible with upstream changes. The integration points: Configuration structure root: /etc/apache2 Logs directory (used when creating a new VirtualHost for redirects): /var/log/apache2 Apache calls: Version check: apache2ctl -v Restart: apache2ctl graceful Config test: apache2ctl configtest List loaded modules: apache2ctl -t -D DUMP_MODULES List Define’d variables: apache2ctl -t -D DUMP_RUN_CFG List Include’d configuration files: apache2ctl -t -D DUMP_INCLUDES We’re also calling a2enmod and and a2dismod scripts to enable / disable modules (like mod_ssl) if needed. -- Joona Hoikkala -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: apache2 package and continued Certbot compatibility
Hi, Thank you for getting in touch. I'm not sure that our test infrastructure currently allows for emails to be sent to third parties on failure, but in any case I'm sure you don't want to be spammed by test failures a majority of which won't be certbot related. One thing I suggest you can do is to write a test suite covering all the functionality on which you're relying (thank you for summarising that) and add the test suite to our packaging, with a note in the failure output to get in touch with you about behaviour changes. Our tests will then run for every change we make to the apache2 package, and will block pending review from a distribution developer. That person will hopefully see your note and get in touch with you well in advance of it causing a problem for users in production. The tool to do all of this is "autopkgtest" which is packaged in Debian and Ubuntu. The documentation is here: https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst Note that Ubuntu's apache2 packaging is derived from Debian's, and that everything I've said above applies to Debian also, so it might be easier to make these test additions in Debian directly, if they are willing to accept them. Hope that helps, Robie On Thu, May 16, 2019 at 05:02:59PM +0300, Joona Hoikkala wrote: > Hello, > > The following message is intended for the maintainers of the apache2 > package: > > We’re maintaining Certbot and it’s Apache plugin on Ubuntu. In the past, > changes to the Apache HTTPd package on different OSes have broken the > way Certbot interacts with web server. We are contacting to let you know > what functionality we are relying on to see if we can find a way to > ensure uninterrupted operability of Certbot on Ubuntu. We would also > love to hear your thoughts about the way we’re currently doing this - > especially if you think there would be a better practice to do some or > all of these actions on Ubuntu. > > If possible, we would also like to get notified if some of the > functionality of these interaction points that we depend on changes, so > we can adapt our code before the functionality breaks for the users. > > If your distribution’s packaging infrastructure allows tests that could > send notifications over to us, it would be a great thing to have. That > said, we definitely do not want to block your development or maintenance > of Apache HTTPd on Ubuntu, but would merely like to keep our software > compatible with upstream changes. > > The integration points: > > Configuration structure root: /etc/apache2 > Logs directory (used when creating a new VirtualHost for redirects): > /var/log/apache2 > > > Apache calls: > > Version check: apache2ctl -v > Restart: apache2ctl graceful > Config test: apache2ctl configtest > List loaded modules: apache2ctl -t -D DUMP_MODULES > List Define’d variables: apache2ctl -t -D DUMP_RUN_CFG > List Include’d configuration files: apache2ctl -t -D DUMP_INCLUDES > > We’re also calling a2enmod and and a2dismod scripts to enable / disable > modules (like mod_ssl) if needed. > > -- > Joona Hoikkala > > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: apache2 package and continued Certbot compatibility
And these are the current tests: https://git.launchpad.net/ubuntu/+source/apache2/tree/debian/tests On Thu, May 16, 2019 at 11:19 AM Robie Basak wrote: > > Hi, > > Thank you for getting in touch. > > I'm not sure that our test infrastructure currently allows for emails to > be sent to third parties on failure, but in any case I'm sure you don't > want to be spammed by test failures a majority of which won't be certbot > related. > > One thing I suggest you can do is to write a test suite covering all the > functionality on which you're relying (thank you for summarising that) > and add the test suite to our packaging, with a note in the failure > output to get in touch with you about behaviour changes. > > Our tests will then run for every change we make to the apache2 package, > and will block pending review from a distribution developer. That person > will hopefully see your note and get in touch with you well in advance > of it causing a problem for users in production. > > The tool to do all of this is "autopkgtest" which is packaged in Debian > and Ubuntu. The documentation is here: > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst > > Note that Ubuntu's apache2 packaging is derived from Debian's, and that > everything I've said above applies to Debian also, so it might be easier > to make these test additions in Debian directly, if they are willing to > accept them. > > Hope that helps, > > Robie > > On Thu, May 16, 2019 at 05:02:59PM +0300, Joona Hoikkala wrote: > > Hello, > > > > The following message is intended for the maintainers of the apache2 > > package: > > > > We’re maintaining Certbot and it’s Apache plugin on Ubuntu. In the past, > > changes to the Apache HTTPd package on different OSes have broken the > > way Certbot interacts with web server. We are contacting to let you know > > what functionality we are relying on to see if we can find a way to > > ensure uninterrupted operability of Certbot on Ubuntu. We would also > > love to hear your thoughts about the way we’re currently doing this - > > especially if you think there would be a better practice to do some or > > all of these actions on Ubuntu. > > > > If possible, we would also like to get notified if some of the > > functionality of these interaction points that we depend on changes, so > > we can adapt our code before the functionality breaks for the users. > > > > If your distribution’s packaging infrastructure allows tests that could > > send notifications over to us, it would be a great thing to have. That > > said, we definitely do not want to block your development or maintenance > > of Apache HTTPd on Ubuntu, but would merely like to keep our software > > compatible with upstream changes. > > > > The integration points: > > > > Configuration structure root: /etc/apache2 > > Logs directory (used when creating a new VirtualHost for redirects): > > /var/log/apache2 > > > > > > Apache calls: > > > > Version check: apache2ctl -v > > Restart: apache2ctl graceful > > Config test: apache2ctl configtest > > List loaded modules: apache2ctl -t -D DUMP_MODULES > > List Define’d variables: apache2ctl -t -D DUMP_RUN_CFG > > List Include’d configuration files: apache2ctl -t -D DUMP_INCLUDES > > > > We’re also calling a2enmod and and a2dismod scripts to enable / disable > > modules (like mod_ssl) if needed. > > > > -- > > Joona Hoikkala > > > > > > > > -- > > Ubuntu-devel-discuss mailing list > > Ubuntu-devel-discuss@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
