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

claircore: open /tmp: operation not supported #2009

Open
kamalpreetSec opened this issue Mar 14, 2024 · 8 comments
Open

claircore: open /tmp: operation not supported #2009

kamalpreetSec opened this issue Mar 14, 2024 · 8 comments

Comments

@kamalpreetSec
Copy link

Description of Problem / Feature Request

We are running Clair in Combo mode. It is running fine with version 4.7.1, but when we upgraded to 4.7.3, getting the 500 internal server error.

Expected Outcome

Scan should run successfully, currently it is failing with 500 internal server error.

Actual Outcome

he scan is failing with 500 internal server error.

2024-03-14T08:58:52Z DBG index error error="unexpected return status: 500" digest=sha256:xxxxxxxxxx ref=/postgres:12.1
2024-03-14T08:58:52Z ERR error="unexpected return status: 500"

Environment

  • Clair version/image: 4.7.3 / image: quay.io/projectquay/clair:4.7.3
  • Clair client name/version: clairctl 4.7.3
  • Host OS: Oracle Linux 7
  • Kernel (e.g. uname -a): 5.4.17-2136.304.4.1.el7uek.x86_64
  • Kubernetes version (use kubectl version): Docker Version: 19.03.11-ol
  • Network/Firewall setup: Corporate proxy
@hdonnay
Copy link
Member

hdonnay commented Mar 14, 2024

Clair 4.7.3 and later require wherever it's configured to write temporary files to support the O_TMPFILE open(2) flag. This has been in the kernel and most in-tree filesystems for over a decade.

What filesystem is mounted at $TMPDIR (or /tmp if that's unset)?

@hdonnay hdonnay changed the title state=FetchLayers 8:58AM ERR error during scan error="failed to fetch layers: fetcher: encountered errors: error realizing layer sha256:xxxxxxxxxxxxxxxxxxx open /tmp: operation not supported" component=indexer/controller/Controller.Index manifest=sha256:xxxxxxxxxxxx request_id=09e112078fc88c09 state=FetchLayers claircore: open /tmp: operation not supported Mar 14, 2024
@kamalpreetSec
Copy link
Author

Its xfs filesystem. It has been mounted to an attached block volume.

/random/tmp /tmp xfs bind,defaults,noatime,_netdev 0 2

where
/dev/mapper/datavg-random--lv /random xfs defaults,noatime,nofail,_netdev 0 2

perat added a commit to perat/clair that referenced this issue Mar 14, 2024
perat added a commit to perat/clair that referenced this issue Mar 14, 2024
Workaround for issue quay#2009
suggested in docker/compose#1339 (comment)

Signed-off-by: perat <perat86@icloud.com>
@hdonnay
Copy link
Member

hdonnay commented Mar 14, 2024

Is the dependency on that mount expressed in the service manager?

@kamalpreetSec
Copy link
Author

yes, the above entries are in /etc/fstab

@kamalpreetSec
Copy link
Author

We checked in logs that open with O_TMPFILE fails.

[~] docksh clairv4
bash-4.4$ /tmp/tmp_file /tmp
Error opening temporary file in /tmp: Operation not supported

Is it possible to place the fix where fall back happens to a non-O_TMPFILE path if the open() fails.

@kamalpreetSec
Copy link
Author

Also, from logs the permissions are 0644, will increasing the permissions help?

openat(AT_FDCWD, "/tmp", O_WRONLY|O_CLOEXEC|O_TMPFILE, 0644

@glebsts
Copy link

glebsts commented Mar 18, 2024

I believe it should move under quay/claircore , there is similar PR quay/claircore#1140
Created quay/claircore#1289


Struggling with same, tmpfs in our cluster and nfsfs for pvc do not support this operation.
Tried also permissions and non-rootless container, overriding TMPDIR etc.
Problem is specifically in flag not supported by docker kernel.

Can there be a patch in clair core similarly to this?
https://github.com/libvips/libvips/pull/1155/files
(original thread with same problem in libvips: libvips/libvips#1151)

@glebsts
Copy link

glebsts commented Apr 5, 2024

fixed with quay/claircore#1292 , waiting for merge and release of #2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants