Re: Getting started

[Colin Walters <walters verbum org>]

On Thu, 2012-07-19 at 13:12 +0100, Sam Thursfield wrote:

> Is there a flag to enable this mode? 

It's important to understand that OSTree is inspired by git, (and I do
call it "git for operating systems"), but this gets to the root of the
important difference.  While you can run git as any user, and that's
totally normal and fine, in contrast, OSTree stores the uid, gid, and
extended attributes of files, like tar does.

You can't pull into a "bare" repository as non-root because it would
imply losing that data.  While it's true that after you did a pull you
could *probably* just do a :

$ chown -R -h root:root /ostree/repo

In the future when we are including SELinux extended attributes, those
would be lost.

The reason I don't immediately error out in ostree-pull 
if getuid() != 0 is because it's theoretically possible to use ostree to
back up your home directory for example, just like how you can use "tar
-C --xattrs /home/username".  Note unlike tar, ostree saves
xattrs by default, you have to use --no-xattrs to disable it.

(I wouldn't really encourage using ostree for /home though...there
 are *plenty* of other programs out there for that)

> Currently in ostree-pull lchown()
> is called anyway, and it returns an error (EPERM) to the main loop.
> I've commented it out for now.

So hopefully it makes sense now *why* that happens =)

> I pushed a branch 'wip/error-handling' which can show what is
> happening a little better.

Yeah...descriptive error messages is hard because in some cases,
GLocalFile will add them, in others it won't =(

But in this case having the path wouldn't have really helped you debug it,
I don't think.  I just pushed a patch to master which should hopefully
make things clearer:

$ pwd
/home/walters/tmp
$ mkdir somerepo
$ ostree --repo=somerepo init  # note this is a "bare" repo
$ /src/build/jhbuild/bin/ostree --repo=somerepo pull-local /ostree/repo trees/gnomeos-3.6-i686-devel
Enumerating objects...
37663 objects to copy
lchown(0, 0) failed: Operation not permitted
$

On your patch content itself; I prefer using g_prefix_error() where
possible because I think error messages read best when they look like:

[program] ... [more context]+ ... [error name]

> I think https://bugzilla.gnome.org/show_bug.cgi?id=679527 is fixed
> too, which is also super helpful. So I now have an OS tree checked
> out!

Cool, though it sounds like it's owned as non-root, which...well, you
could *probably* boot into it if you chowned it, you're really going to
have to switch to doing the administrative operations as root.

It is lame that ostree-pull is doing HTTP as root, but
we share this flaw with apt-get/zypper/yum/etc.  There's no fundamental
reason though we couldn't have a split-process downloading architecture
where all of the HTTP stuff happens as user "nobody", possibly
sandboxed further with SELinux/seccomp or whatever, and then we
verify the file checksums in the master process and import them.