On Dienstag, 13. Mai 2014, 23:45:12 wrote Ruediger Meier:

Hi,

is it possible to run a command from %build section as root? I thought it's possoble somehow but can't find it.

Not by default. You could add # userootforbuild in the spec file and we would need to add an exception on the server side for this package. Better you find another way :) -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Mittwoch, 14. Mai 2014, 09:17:08 wrote Lars Weber:

I use a package root4abuild created via attached spec-file. Use this package as a build-requirement for your package and you can gain root-rights for abuild via sudo during the build-process.

Might be a little bit ugly but works for me.

You should make sure not to publish that package, because a user would create a security hole in his system. Also the package will never be accepted in Factory. So if your goal is to create an official package you should look for another solution :) (It is not an issue for OBS, since we use KVM/XEN secured environments in case you wonder) -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 05/14/2014 11:11 AM, Ruediger Meier wrote:

IMO this is a general use case, worth to think about, see for example $ osc rbl -s Base:System coreutils-testsuite openSUSE_Factory i586 |\ grep "must be run as root" setgid.sh: skipped test: must be run as root basic.sh: skipped test: must be run as root cp-a-selinux.sh: skipped test: must be run as root preserve-gid.sh: skipped test: must be run as root special-bits.sh: skipped test: must be run as root cp-mv-enotsup-xattr.sh: skipped test: must be run as root capability.sh: skipped test: must be run as root [...]

I already asked that for coreutils some while ago (I'm a co-maintainer). So if someone can point to a valid solution - also for Factory - then I'd be grateful. Thanks & have a nice day, Berny -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Mittwoch, 14. Mai 2014, 13:05:36 wrote Jan Engelhardt:

On Wednesday 2014-05-14 12:55, Bernhard Voelker wrote:

...

On 05/14/2014 11:11 AM, Ruediger Meier wrote:

...

IMO this is a general use case, worth to think about, see for example $ osc rbl -s Base:System coreutils-testsuite openSUSE_Factory i586 |\ grep "must be run as root" setgid.sh: skipped test: must be run as root basic.sh: skipped test: must be run as root cp-a-selinux.sh: skipped test: must be run as root preserve-gid.sh: skipped test: must be run as root special-bits.sh: skipped test: must be run as root cp-mv-enotsup-xattr.sh: skipped test: must be run as root capability.sh: skipped test: must be run as root [...]

I already asked that for coreutils some while ago (I'm a co-maintainer). So if someone can point to a valid solution - also for Factory - then I'd be grateful.

Didn't we have

#!rootneededforbuild

or so?

Yes, but it needs also an exception on the server side for that package. While I understand that root access is really needed for a lot of test cases, we want to ensure that build src.rpms do not damage a user system. Therefor we will also not allow root for building rpms in future. But we will work on QA features (hopefully later this year). And I take this as input for them ... -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Wednesday 14 May 2014, Adrian Schröter wrote:

On Mittwoch, 14. Mai 2014, 13:05:36 wrote Jan Engelhardt:

...

On Wednesday 2014-05-14 12:55, Bernhard Voelker wrote:

...

On 05/14/2014 11:11 AM, Ruediger Meier wrote:

...

IMO this is a general use case, worth to think about, see for example $ osc rbl -s Base:System coreutils-testsuite openSUSE_Factory i586 |\ grep "must be run as root" setgid.sh: skipped test: must be run as root basic.sh: skipped test: must be run as root cp-a-selinux.sh: skipped test: must be run as root preserve-gid.sh: skipped test: must be run as root special-bits.sh: skipped test: must be run as root cp-mv-enotsup-xattr.sh: skipped test: must be run as root capability.sh: skipped test: must be run as root [...]

I already asked that for coreutils some while ago (I'm a co-maintainer). So if someone can point to a valid solution - also for Factory - then I'd be grateful.

Didn't we have

#!rootneededforbuild

or so?

Yes, but it needs also an exception on the server side for that package.

While I understand that root access is really needed for a lot of test cases, we want to ensure that build src.rpms do not damage a user system.

Therefor we will also not allow root for building rpms in future.

But we will work on QA features (hopefully later this year). And I take this as input for them ...

Maybe you could do like this If specfile contains "#!needsudoforbuild" then OBS adds silently /etc/sudoers.d/abuild and also provides macro %have_abuild_sudo. rpmlint could check that any sudo is guarded by "%if %have_abuild_sudo" to make sure that we would never call sudo from spec file even if that paricular user has sudo permissions already. But user is still free to provide %have_abuild_sudo on local rpmbuild command line if he knows what he is doing. cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Adrian Schröter wrote:

On Mittwoch, 14. Mai 2014, 13:05:36 wrote Jan Engelhardt:

...

On Wednesday 2014-05-14 12:55, Bernhard Voelker wrote:

...

On 05/14/2014 11:11 AM, Ruediger Meier wrote:

...

IMO this is a general use case, worth to think about, see for example $ osc rbl -s Base:System coreutils-testsuite openSUSE_Factory i586 |\ grep "must be run as root" setgid.sh: skipped test: must be run as root basic.sh: skipped test: must be run as root cp-a-selinux.sh: skipped test: must be run as root preserve-gid.sh: skipped test: must be run as root special-bits.sh: skipped test: must be run as root cp-mv-enotsup-xattr.sh: skipped test: must be run as root capability.sh: skipped test: must be run as root [...]

I already asked that for coreutils some while ago (I'm a co-maintainer). So if someone can point to a valid solution - also for Factory - then I'd be grateful.

Didn't we have

#!rootneededforbuild

or so?

Yes, but it needs also an exception on the server side for that package.

While I understand that root access is really needed for a lot of test cases, we want to ensure that build src.rpms do not damage a user system.

You cannot guarantee that with chroot anyways. After all a package could buildrequire another one that does something nasty in %post as root. So disallowing build as root just adds one level of indirection but doesn't prevent any code from getting executed as root. So the idea of having an extra package that configures the system in a way that the abuild user is allowed to run stuff as root doesn't sound too bad to me. The package could even be set up in a way that it cannot be installed outside of build environments by means of invalid requires, just like various *-mini packages do. To avoid an extra build requirement on sudo a line like auth sufficient pam_succeed_if.so use_uid user = abuild in /etc/pam.d/su-l would do as well. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 05/14/2014 03:08 PM, Ruediger Meier wrote:

For now you could use Lars' trick like I'am doing now in home:rudi_m:branches:Base:System/util-linux

Thanks, but I don't want to put energy into a "hack" of the package in my personal repo. I'd favor an officially supported and accepted solution that is also permitted in o:F. In my eyes it would be a plus regarding quality of openSUSE if we could say "hey, we even passed the root-tests". For coreutils at least, the build system on openSUSE currently runs and passes much more tests compared to Fedora for example. As there seem to be several guys/packages needing root privs, I think the current discussion is a step in the right direction. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 05/14/2014 10:33 PM, Marcus Meissner wrote:

We tried very hard not to run stuff as root over years, making it too easy now to revert this, is probably bad.

That's exactly why I don't like a hack but an all-accepted solution. E.g. a whitelist of complete command line strings which are permitted to run as root in an OBS chroot. And a macro %sudo which checks the given command against the whitelist before chaning to root. By that, the security and quality team would have fine-grained control over what is permitted. E.g. for coreutils-testsuite, only the command string 'env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root' would need to be added. The spec file could define it like %sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root and that macro could verify that exactly that string is permitted. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

# mail@bernhard-voelker.de / 2014-05-14 22:51:56 +0200:

On 05/14/2014 10:33 PM, Marcus Meissner wrote:

...

We tried very hard not to run stuff as root over years, making it too easy now to revert this, is probably bad.

That's exactly why I don't like a hack but an all-accepted solution. E.g. a whitelist of complete command line strings which are permitted to run as root in an OBS chroot. And a macro %sudo which checks the given command against the whitelist before chaning to root. By that, the security and quality team would have fine-grained control over what is permitted.

E.g. for coreutils-testsuite, only the command string 'env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root' would need to be added. The spec file could define it like %sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root and that macro could verify that exactly that string is permitted.

limiting the privileged commandline to an invocation of a third-party program does little to improve security. perhaps if the root mode could be limited to vm builds (no chroots)? -- roman -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 05/14/2014 11:18 PM, Roman Neuhauser wrote:

limiting the privileged commandline to an invocation of a third-party program does little to improve security.

And of course, such a whitelist must include the package name, i.e., another package could not use the same string to circumvent the restriction (unless it has registered the same string for %sudo, too). That's all ideas only. Unfortunately, I don't know OBS internals enough for proposing a detailed solution. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Wednesday 14 May 2014, Bernhard Voelker wrote:

On 05/14/2014 10:56 PM, Ruediger Meier wrote:

...

Of course but since you are also upstream active it could be just interesting to discover some bugs.

I already did that in the past - that's why 'make check-very-expensive' now passes on OBS only with a little set of NOPed-out tests, and with very little false-positive fallout. ;-)

...

OBS build hosts are somehow special

in comparison to real full-featured machines.

You can tell! Most problems are timing issues because e.g. the file system performance is sometimes not that predictable. And there's things like aarch64 ...

Hehe I know. Recently I've spent a few weeks to fix almost everything for util-linux' non-root checks. Now I've started to review root checks ... again a lot of work. But it's worth! While most issues just needed to be fixed in the test-suite itself, a few ones weretrue bugs. But the most benefit is that, once the tests are fixed we can enable them on OBS to discover newly added bugs automatically. Thats why we should run tests as complete as possible inclusive sudo. cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Mittwoch, 14. Mai 2014, 23:50:37 wrote Bernhard Voelker:

On 05/14/2014 10:56 PM, Ruediger Meier wrote:

...

Of course but since you are also upstream active it could be just interesting to discover some bugs.

I already did that in the past - that's why 'make check-very-expensive' now passes on OBS only with a little set of NOPed-out tests, and with very little false-positive fallout. ;-)

...

OBS build hosts are somehow special in comparison to real full-featured machines.

You can tell! Most problems are timing issues because e.g. the file system performance is sometimes not that predictable. And there's things like aarch64 ...

I would see this the other way around, also in real life you can have a loaded system. And it is no good your software fails, when it is not an exlusive for you reserved system :) -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Thu, May 15, 2014 at 3:26 AM, Adrian Schröter wrote:

On Mittwoch, 14. Mai 2014, 23:18:48 wrote Roman Neuhauser:

...

# mail@bernhard-voelker.de / 2014-05-14 22:51:56 +0200:

...

On 05/14/2014 10:33 PM, Marcus Meissner wrote:

...

We tried very hard not to run stuff as root over years, making it too easy now to revert this, is probably bad.

That's exactly why I don't like a hack but an all-accepted solution. E.g. a whitelist of complete command line strings which are permitted to run as root in an OBS chroot. And a macro %sudo which checks the given command against the whitelist before chaning to root. By that, the security and quality team would have fine-grained control over what is permitted.

E.g. for coreutils-testsuite, only the command string 'env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root' would need to be added. The spec file could define it like %sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root and that macro could verify that exactly that string is permitted.

limiting the privileged commandline to an invocation of a third-party program does little to improve security. perhaps if the root mode could be limited to vm builds (no chroots)?

It is not about security. It is to avoid that we get unclean src.rpms in first place.

We improved there a lot, in old times we had plenty of src.rpms which were modifying the users system when you build it.

I've heard the security argument several times on the list, though. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org