Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Thu, Aug 02, 2018 at 01:29:26PM -0700, Kees Cook wrote: > > > > - Users who are unpacking root tarballs need to take care to pass > > > >--xattrs-include=* to tar. > > > > - Users who are backing up or streaming Ubuntu root filesystems with > > > > tar or > > > >rsync will need to take care to pass non-default xattr-preserving > > > > options > > > >(tar --xattrs; rsync -X). > > > How about making these default-enabled? Hoping people will remember seems > > > fragile. > > I think that's appropriate to pursue with the upstream, but that we should > > still socialize the recommendation to use the options explicitly for > > portability. > While I agree about pursuing it with upstreams, I don't agree about just > leaving this to documentation/luck. The problem is distro-specific (i.e. > the packages built and the root filesystem being used), so I think it's > fair to make the tools involved in that distro DTRT by default when it > comes to xattrs. (Everything else is expected to work together correctly, > why not the tools too?) I don't think this is an either-or proposition. I think we need to document it because existing tooling doesn't DTRT by default, and I think we need to work with upstream to get the defaults changed (upstream, because we can't assume that our users are using Ubuntu's tar binary when unpacking Ubuntu root tarballs). I've filed two bugs in launchpad for this on the respective packages. https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1785291 https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1785302 -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote: > This will require bugfixes in various places, but ideally on a one-time > basis only. The primary areas of concern are: I think launchpad-buildd needs a couple of fixes for this, but there are some things to fix that aren't quite one-liners. Firstly, we need to pass --xattrs-include=* when unpacking chroots. That much is straightforward. Secondly, the machinery that creates Launchpad build chroots needs to pass --xattrs. That machinery is currently Adam Conrad's shell history, but we're in the process of moving it into livecd-rootfs, and that will need a minor adjustment. The third problem is the one that isn't trivial. Some Launchpad builds are run in LXD containers rather than in chroots, and in those cases we first mangle the chroot tarball into a shape that can be imported by LXD. We currently do this using Python 2.7's tarfile module, but as far as I can see that doesn't quite support xattrs properly due to encoding issues. I can think of a couple of options: * We could take some approach like https://github.com/docker/docker-registry/pull/381/files to monkey-patch tarfile, or we could finish the upgrade of launchpad-buildd to Python 3 (which is within reach). In either case, we'd need to work out how to invoke tarfile correctly to preserve xattrs; I think that's probably a fairly small change, but it'll require some investigation and testing. * Once we've completed the move of chroot creation into livecd-rootfs, it may be practical to have that produce LXD containers too, and in that case we could drop the Python-based mangling. In the long term this would be preferable because it would save a minute or two at the start of many builds. None of this is super-urgent since I don't think there's anything in the chroots that requires xattrs, but we should remember to fix it to avoid future surprises. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Globally refreshing new group membership - would be needed after some package installations
On Fri, Aug 03, 2018 at 12:13:15PM +0100, Robie Basak wrote: > Yeah, so for example starting virt-manager from the desktop shell will > continue to be a problem until the next login session. Actually, now that I think about it, we could adjust the desktop file to use a wrapper there also. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Globally refreshing new group membership - would be needed after some package installations
On Fri, Aug 3, 2018 at 1:13 PM Robie Basak wrote: > On Fri, Aug 03, 2018 at 12:13:30PM +0200, Christian Ehrhardt wrote: > [...] > > - And the UI itself when click-starting things will not have changed > > Yeah, so for example starting virt-manager from the desktop shell will > continue to be a problem until the next login session. Do you have any > solution in mind for this? No better idea, which was why I was asking for the Mass-Intelligence of Ubuntu-Devel :-) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Globally refreshing new group membership - would be needed after some package installations
On Fri, Aug 03, 2018 at 12:13:30PM +0200, Christian Ehrhardt wrote: > If working this could maybe fixup the terminal it is running in but not > more than that. Yes - it would be limited in scope. But for CLI tools (say lxc), if lxc is wrapped with newgrp, then it should be sufficient. > - And the UI itself when click-starting things will not have changed Yeah, so for example starting virt-manager from the desktop shell will continue to be a problem until the next login session. Do you have any solution in mind for this? Apart from something quite invasive (eg. getting the desktop shell to re-exec itself via newgrp, or ptrace except that's disabled by default, etc, or not using groups, or kernel support for messing with group membership of other processes, and/or something that walks a cgroup modifying group memberships) I don't see any solution. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Globally refreshing new group membership - would be needed after some package installations
On Thu, Aug 2, 2018 at 1:32 PM Robie Basak wrote: > On Thu, Aug 02, 2018 at 01:16:04PM +0200, Christian Ehrhardt wrote: > > I was wondering if there is a common pattern to resolve this that might > > just be unknown to me yet and that I could use in packaging. > > I have in mind to write a wrapper that checks if "newgrp" or "sg" would > succeed and exec itself via that if so. I'm not aware of this being an > existing pattern though. > > If we wanted to make it a standard thing, we could provide such a > wrapper in a package and then packages that wanted to use it could > register with (and symlink to) the wrapper. > If working this could maybe fixup the terminal it is running in but not more than that. - New terminals started from UI might still have old group membership (if not a new login) - And the UI itself when click-starting things will not have changed I'm a console guy myself, but that would only only fix part of the problem :-/ Especially as the console-addicted folks are those who would mostly have known "that they have to" and "how to" refresh their groups. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
