search

gramineproject / gsc

Gramine Shielded Containers (Docker integration)
BSD 3-Clause "New" or "Revised" License
44 stars 37 forks source link

gsc build for SUSE distro workloads with Permission denied error #215

Closed anjalirai-intel closed 1 month ago

anjalirai-intel commented 1 month ago

Description of the problem

GSC templates for SUSE reads /etc/zypp/credentials.d/SCCcredentials file, the credentials file does not have read permssions for the current user, hence gsc build fails when it is trying to read this file

$ ls -al /etc/zypp/credentials.d/SCCcredentials -rw------- 1 root root 122 Sep 9 13:14 /etc/zypp/credentials.d/SCCcredentials

Steps to reproduce

./gsc build -nc --insecure-args bash-test test/ubuntu20.04-bash.manifest

Expected results

GSC Build should be successful, it should not throw any error

Actual results

+ ./gsc build -nc --insecure-args bash-test test/ubuntu20.04-bash.manifest
Building unsigned graminized Docker image `gsc-bash-test-unsigned` from original application image `bash-test`...
Warning: Duplicate key `loader.env.PATH`. Concatenating values from `<merged test/ubuntu20.04-bash.manifest and suse/entrypoint.manifest.template>` and `<bash-test image env>`.
Traceback (most recent call last):
  File "./gsc", line 12, in <module>
    sys.exit(main(sys.argv))
  File "./gsc.py", line 750, in main
    return args.command(args)
  File "./gsc.py", line 456, in gsc_build
    handle_suse_repo_configs(distro, tmp_build_path)
  File "./gsc.py", line 260, in handle_suse_repo_configs
    shutil.copyfile('/etc/zypp/credentials.d/SCCcredentials', tmp_build_path / 'SCCcredentials')
  File "/usr/lib64/python3.6/shutil.py", line 120, in copyfile
    with open(src, 'rb') as fsrc:
PermissionError: [Errno 13] Permission denied: '/etc/zypp/credentials.d/SCCcredentials'

Resolution

Change the file permissions to read/write for current user

mkow commented 1 month ago

How is it possible that this wasn't noticed during review? No one tested the PR? What about CI, I thought that internal Intel CI was testing this?

adarshan-intel commented 1 month ago

How is it possible that this wasn't noticed during review? No one tested the PR? What about CI, I thought that internal Intel CI was testing this?

This PR was tested on the same opensuse machine used for development. During development, I modified the file permissions to enable reading, and these permissions remained the same during testing. Therefore, this issue was not identified in CI. The read operation is necessary to copy the credential file into the Docker image for installing packages, yet granting read permissions could expose sensitive data to all users. Is there a solution we can devise to address this issue?

dimakuv commented 1 month ago

SUSE Support simply recommends granting the current user the read access to this file:

mkow commented 1 month ago

This PR was tested on the same opensuse machine used for development

vs

Therefore, this issue was not identified in CI.

I don't understand, does this mean that you're developing on CI machines and they aren't separate? So, every change you make persistently changes the CI environment?

anjalirai-intel commented 1 month ago

This PR was tested on the same opensuse machine used for development

vs

Therefore, this issue was not identified in CI.

I don't understand, does this mean that you're developing on CI machines and they aren't separate? So, every change you make persistently changes the CI environment?

@mkow We typically don't do testing and developing on the same infra. However, due to a host dependency for SUSE and a lack of available machines to reflash to SUSE, we conducted testing on the same infra.

adarshan-intel commented 1 month ago

SUSE Support simply recommends granting the current user the read access to this file:

@mkow According to this, issue should be resolved once the customer grants read access to the credentials file. Where should we include this comment?

dimakuv commented 1 month ago

@adarshan-intel @anjalirai-intel Do we even think this is an important note to have? I would imagine that commercial SUSE users know about this requirement, or can quickly contact SUSE support. The error from GSC is pretty clear, and I feel like there's no need for additional pretty-printing.

adarshan-intel commented 1 month ago

@adarshan-intel @anjalirai-intel Do we even think this is an important note to have? I would imagine that commercial SUSE users know about this requirement, or can quickly contact SUSE support. The error from GSC is pretty clear, and I feel like there's no need for additional pretty-printing.

I agree, therefore I think no additional fixes are required and we can proceed to close this issue.

anjalirai-intel commented 1 month ago

@dimakuv We don't have any such ask from validation perspective. If this is a common thing for SUSE we are okay taking no action for issue

adarshan-intel commented 1 month ago

SUSE Support simply recommends granting the current user the read access to this file:

@dimakuv @mkow I believe this answers the issue, so can we go ahead and close this? Or it requires any further action?

dimakuv commented 1 month ago

Fine from my side to just close this issue.