non sudo build

non sudo build

['mdolli...@googlemail.com' via isar-users]

[-- Attachment #1.1: Type: text/plain, Size: 590 bytes --]

Hi all,

I would like to build isar as non sudo user. I found a feature for this, 
but the latest comments are 2 years old:
- https://github.com/ilbers/isar/issues/11

Are there any new updates to that topic?

Thanks in advance!
Marc

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/200a5c93-d152-4217-89a0-7549a3d474b4n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 961 bytes --]

Re: non sudo build

[Roberto A. Foglietta]

On Fri, 14 Mar 2025 at 09:23, 'mdolli...@googlemail.com' via
isar-users <isar-users@googlegroups.com> wrote:
>
> Hi all,
>
> I would like to build isar as non sudo user. I found a feature for this, but the latest comments are 2 years old:
> - https://github.com/ilbers/isar/issues/11
>
> Are there any new updates to that topic?
>

jan-kiszka on May 24, 2022 Contributor

The topic is not forgotten, "just" not the most urgent one right now.
That's also because it remains hard with a real distribution that does
not have this case on its "normal" path.

Some background, others may add more: We need a solution that is in
line with official Debian installation here. Neither polystrap nor
multistrap are maintained anymore. An option we have currently on the
horizon is DPKG_ROOT, but that requires support of the packages, thus
is nothing you do "over night".

https://github.com/ilbers/isar/issues/11#issuecomment-1135415963

***

PREMISE

The idea to complain with Debian or whatever else decision makers
external to a project is fundamentally wrong under the perspective of
supporting a user-base that might not be even interested in tha OS.
Because it is equivalent to say that the support of a project depends
on the will of somebody else whom are not involved in the project nor
a stakeholder of it. So, this explanation should be rejected in total.

Moreover, this approach is also against open source and free software,
the main idea for which people whom have source code and skills can
take care of themselves or sell their skill to others for the same
goal. Under this PoV saying that X or Y projects can achieve a goal
but should be discarded because they are not currently supported is
absurd as long as the source is available, one project could resume
from that source and a dedicated support can be provided in order to
integrate with the main project needs.

***

LONG TO READ

The question is - that source code, related maintenance and
integration - are worth the effort rather than a generic approach of a
user-land virtual machine? Usually a user-land machine is available
but it might not be universally true or the performance might be
sensitively lower than a real machine executing the same task in
user-land. Because virtualisation can provide near real-hardware
performance when a virtual machine has the right to access to hardware
in a "passthrough" mode and this requires fine-grained privileges that
are constantly a risk being a backdoor (or potential) to escalate root
privileges and requires effort to be set and maintained within a
certain degree of security. Which usually brings the companies to
provide a root-access to engineers on some machine that CANNOT join
the company network but just a LAB network.

Unfortunately, also the LAB network might contain a certain amount of
sensitive data which should be protected and this raises the concern
of using developing tools that require root password. Something that
led responsable engineers to segregate these DEV machines into a
relatively isolated LAB sub-lan. So, a reasonable answer can be: ISAR
is not the only DEV tool that requires root privileges, provide
yourselves the proper hardware/network supply/settings to deal with
all those cases similar to ISAR.

Then, for someone ISAR can be the ONLY dev tool that requires such a
privileged root access. This implies that all the costs related to
deal with this requirement would be accounted in total to ISAR center
of cost. Plus, from a manager PoV, when ISAR is the ONLY one that
requires an investment or a policy change, then it is also the first
of a series. Because at that point - engineers will not do that extra
mile they need to run a dev tool into a user-land environment but
switch to the "exception" created for ISAR mixing data that were NOT
supposed to be mixed and fragments of them could be included into ISAR
products.

For example sensitive data can be leaked because the files which
contain the root filesystem have holes but when dd is used the raw
data might be collected and hence the data which has not be zerood.
You might argue that this is not going to happen - bla bla -
irrelevant, I might be wrong in citing a practical example but it can
exist. In particular it exists - at least in theory and because
ignoring details - into a non-technical decision maker like a manager.

Who cares about professional users? Open source and free software is
for hobbyists and not for professionals. Companies that wish to use
that solution SHOULD pay for professional support. Then wrote that
explicitly: this feature is available ONLY for those buying
professional support. Which in this case means - after reading the
comment above - support Debian with a donation and hope for the best.
Name a company manager that will consider such a kind of action as
"professional support" whatever that support is provided "with granted
results" or "best-effort" formula?

***

IN SHORT

Whatever Debian is going to do, it is not a matter of ISAR. As long as
a project can solve the problem and the source is available then the
maintenance of that software should be included in ISAR - or into ISAR
activities - when anyone else is currently in charge of or not willing
to consider the needs as their priorities Which is the reason because
forks and alternatives exist. Finally, supporting ISAR for working
with not-root privileges is a decision that should be escalated to
those who are business stakeholders of ISAR development.

***

RATIONALE

Considering that ISAR is an open-source project anyone has a business
interest in developing that feature and supporting the tools that can
be used for, then that stakeholder should be put in condition of
contributing to the mainstream in such a way that feature will be
available also in future versions of ISAR. Which is - fundamentally -
the HUGE difference between sw-libre and open-source PoVs: community
vs stakeholders. Community driven by consensus and Stakeholders driven
by I-need-then-I-do-it attitude. Which is also the difference between
putting the human real-world needs before abstract concepts:
pragmatism vs ideology.

***

I hope this helps,
-- 
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/CAJGKYO4NzY334X%3DV3ZmdxvwvF2vPSJ2NanWj%3DbJk4bgpZKHYpw%40mail.gmail.com.

Re: non sudo build

[Baurzhan Ismagulov]

Hello Marc,

On 2025-03-14 01:23, 'mdolli...@googlemail.com' via isar-users wrote:
> I would like to build isar as non sudo user. I found a feature for this, 
> but the latest comments are 2 years old:
> - https://github.com/ilbers/isar/issues/11
> 
> Are there any new updates to that topic?

Depending on what you mean with "build Isar as non-sudo user", one answer could
be to use kas-container as normal user. But the container is privileged and
runs Isar with sudo calls.

Regarding the sudo state in Isar:

1. sbuild has been merged
2. mmdebstrap has been merged
3. Removing the sudo calls is TODO

Historically, the main issue with sudo was mounting and chrooting which was
difficult to solve in their entirety with the existing tools like fakeroot,
fakechroot, pseudo, PRoot, etc.

Steps #1 and #2 account for little number of sudo calls but are important for
greatly reducing the number of mounting occasions.

For #3, we need to classify the sudo calls and possibly provide some API either
to access files within the rootfs, or to chroot into the rootfs and do stuff --
both without sudo. This will affect downstreams but this is a necessary step.
This topic is being addressed at idle priority.

With kind regards,
Baurzhan

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/Z9Rc1gswIztai5dZ%40abai.de.