[opensuse-buildservice] run commands from spec file as root
Hi, is it possible to run a command from %build section as root? I thought it's possoble somehow but can't find it. cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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
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. Cheers, Lars Am 13.05.2014 23:45, schrieb 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.
cu, Rudi
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 Wednesday 14 May 2014, Adrian Schröter wrote:
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.
Thanks Lars! This should do it for me.
You should make sure not to publish that package, because a user would create a security hole in his system.
I'd like to protect local builds in chroot too to not crash my own or other's systems. Can I find out whether the spec file is running on OBS to disable sudo if not?
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 :)
For me there is no other solution. I want to run "util-linux" advanced test-suite as root to see more issues. For now just for debugging but if it turns out to be useful I would like to have it "upstream" in Base:System. Maybe another project "util-linux-testsuite" which does not goes to Factory? 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 skip-seek-past-dev.sh: skipped test: must be run as root problematic-chars.sh: skipped test: must be run as root bind-mount-dir-cycle.sh: skipped test: must be run as root install-C-root.sh: skipped test: must be run as root capability.sh: skipped test: must be run as root nameless-uid.sh: skipped test: must be run as root chcon.sh: skipped test: must be run as root chroot-credentials.sh: skipped test: must be run as root selinux.sh: skipped test: must be run as root truncate-owned-by-other.sh: skipped test: must be run as root writable-under-readonly.sh: skipped test: must be run as root sticky-to-xpart.sh: skipped test: must be run as root fail-2eperm.sh: skipped test: must be run as root no-give-up.sh: skipped test: must be run as root one-file-system.sh: skipped test: must be run as root read-only.sh: skipped test: must be run as root append-only.sh: skipped test: must be run as root now-owned-by-other.sh: skipped test: must be run as roo
(It is not an issue for OBS, since we use KVM/XEN secured environments in case you wonder)
Do you know whether these ones would work on OBS?: modprobe loop losetup ... modprobe scsi_debug I know it does not work for certain other secured VMs. cu, Rudi -- 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 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? -- 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 05/14/2014 01:10 PM, Adrian Schröter wrote:
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 ...
Thanks. To be clear: coreutils-testsuite does not need to %build as root, and in fact successfully runs *many* tests as non-root today, but I would like to run the root-tests, too [1]. Something like: %check ... make check-very-expensive # run non-root tests sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER \ make -k check-root # now run root tests ... A new macro %obssudo would be cool ... ;-) [1] https://build.opensuse.org/package/view_file/Base:System/coreutils-testsuite... Thanks & have a nice day, Berny 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 01:10 PM, Adrian Schröter wrote:
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 ...
Thanks. To be clear: coreutils-testsuite does not need to %build as root, and in fact successfully runs *many* tests as non-root today, but I would like to run the root-tests, too [1]. Something like:
%check ... make check-very-expensive # run non-root tests sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER \ make -k check-root # now run root tests ...
For now you could use Lars' trick like I'am doing now in home:rudi_m:branches:Base:System/util-linux BuildRequires: root4abuild .... sudo -E make check ... You could aggregate root4abuild from home:rudi_m. There I have a rpmlint fixed package for most distros and archs. cu, Rudi -- 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 Wed, May 14, 2014 at 10:29:28PM +0200, Bernhard Voelker wrote:
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.
We tried very hard not to run stuff as root over years, making it too easy now to revert this, is probably bad. Ciao, Marcus -- 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 Wed, May 14, 2014 at 6:56 PM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
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).
And I'd include sha-something of the source tarball. Just an idea. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thursday 15 May 2014, Claudio Freire wrote:
On Wed, May 14, 2014 at 6:56 PM, Bernhard Voelker
<mail@bernhard-voelker.de> wrote:
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).
And I'd include sha-something of the source tarball. Just an idea.
I don't think we have a security problem on OBS. It's just about reliability. If for example a package silently configures /sys, /etc and /usr/lib to be able to compile and run then it might not run correctly after installed on arbitrary target system. I'd say it would be enough to allow sudo for the %check section only. We only have to protect people who want to rebuild src rpms locally and do not want to crash their systems. But that's easy. 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: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. -- 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 <adrian@suse.de> 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
On Wednesday 14 May 2014, Bernhard Voelker wrote:
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.
Of course but since you are also upstream active it could be just interesting to discover some bugs. OBS build hosts are somehow special in comparison to real full-featured machines. Chance to discover bugs in the is high. And fixing bugs is maybe not such a waste of time ;) cu, Rudi -- 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: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 ... 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 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 Wed, May 14, 2014 at 11:57 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
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.
When I was packaging for OpenCSW (Solaris) we used Debians 'fakeroot' to work around running as non-root users. While it's not currently available it might be an option. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (10)
-
Adrian Schröter -
Bernhard Voelker -
Claudio Freire -
Darin Perusich -
Jan Engelhardt -
Lars Weber -
Ludwig Nussel -
Marcus Meissner -
Roman Neuhauser -
Ruediger Meier