Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ebuild and first release #30

Open
TheChymera opened this issue Mar 4, 2019 · 5 comments
Open

Ebuild and first release #30

TheChymera opened this issue Mar 4, 2019 · 5 comments

Comments

@TheChymera
Copy link
Member

TheChymera commented Mar 4, 2019

As the package approaches some general-purpose usability, we should be looking to provide it via a more popular overlay, or directly via the main Gentoo overlay.

I have set-up a live ebuild on my overlay, and as soon as this works reliably we can release a ~stable version. Perhaps this would also be a good time for implementing a rudimentary test suite? e.g. at least for stemgentoo or for creating images of a gebuilder-single-purpose system.

@Doeme would you be interested in testing the ebuild and incorporating/updating the test phase?

@Doeme
Copy link
Member

Doeme commented Mar 4, 2019

Sure, why ever not. Let's try to get this package up to speed

@Doeme
Copy link
Member

Doeme commented Mar 4, 2019

What I don't like about the ebuild: non-privileged users can execute the gebuildscript and get some cryptic error messages smacked in their face.

How can we prevent this? I can think of three options:

  • Moving gebuild into /usr/sbin, which is only in root's path. Contra: AFAIK programs like this don't usually belong into /usr/sbin
  • chmod'ing gebuild to 0700. Script is then still in non-root users $PATH, but at least executing it yields permission denied
  • Checking $USER for != root at the beginning of gebuild, and bail out with a more graceful error message

Otherwise, the ebuild installed flawlessly and the stemgentoo is already set up

@TheChymera
Copy link
Member Author

TheChymera commented Mar 5, 2019

Is there any reason why we wouldn't instead just allow users to create gebuild systems? If it's doable from the workflow point of view it shouldn't be a problem that a user has “root” access inside a subsystem, it would actually be preferable from the point of view of high-power multi-user systems.

@Doeme
Copy link
Member

Doeme commented Mar 5, 2019

Yes, chroot'ing is a privileged operation and therefore can not be performed by any other than root.

Maybe, at some point, we could consider instead of chrooting starting a lxc container (which would be a plus due to better isolation, see also #32). But I haven't looked into that, so I can't say whether this is feasible.

@TheChymera
Copy link
Member Author

Too bad :( well, ok, we can add this to the 2.0 milestones, and in the meantime, since we know explicitly that the user has to be root regardless of permissions, I think

Checking $USER for != root at the beginning of gebuild, and bail out with a more graceful error message

makes the most sense.

@TheChymera TheChymera modified the milestone: Release 2.0 Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants