General permissions check before doing the build

fepitre commented

2021-08-23 07:27:30 +00:00

It has been encountered permissions issue (end of https://debian.notset.fr/rebuild/log-fail/debian-unstable-cpio-2.13%2Bdfsg-7.all-1629665807.log) while running mmdebstrap as root mode when destination folder for a sync-out hook is mounted as a user ssh mount point (without allow_others).

If such a behavior could have been anticipated, I would propose to check if a general sanitize check can be done before proceeding to the actual build on different locations that a user is intended to provide to mmdebstrap.

It has been encountered permissions issue (end of https://debian.notset.fr/rebuild/log-fail/debian-unstable-cpio-2.13%2Bdfsg-7.all-1629665807.log) while running mmdebstrap as root mode when destination folder for a sync-out hook is mounted as a user ssh mount point (without allow_others). If such a behavior could have been anticipated, I would propose to check if a general sanitize check can be done before proceeding to the actual build on different locations that a user is intended to provide to mmdebstrap.

fepitre commented

2021-08-23 07:33:35 +00:00

Author

I would add also that testing on another example (leading to the same permission issues), adding allow_others on the sshfs option mount point being the sync-out destination leads to other error like:

tar: ./gzip-1.10/debian/.debhelper/gzip/dbgsym-root/usr/share/doc/gzip-dbgsym: Cannot utime: No such file or directory
tar: ./gzip-1.10/debian/.debhelper/gzip/dbgsym-root/usr/share/doc/gzip-dbgsym: Cannot change ownership to uid 1000, gid 1000: No such file or directory

I'm currently investigating how to workaround that.

I would add also that testing on another example (leading to the same permission issues), adding `allow_others` on the sshfs option mount point being the sync-out destination leads to other error like: ``` tar: ./gzip-1.10/debian/.debhelper/gzip/dbgsym-root/usr/share/doc/gzip-dbgsym: Cannot utime: No such file or directory tar: ./gzip-1.10/debian/.debhelper/gzip/dbgsym-root/usr/share/doc/gzip-dbgsym: Cannot change ownership to uid 1000, gid 1000: No such file or directory ``` I'm currently investigating how to workaround that.

josch commented

2021-08-23 08:03:06 +00:00

Owner

I'm not sure in which way mmdebstrap could possibly do any checks here. Suppose somebody runs mmdebstrap with:

--customize-hook="sync-out /foo ./bar"

If I understand you correctly, then you would like mmdebstrap to check if ./bar is even writable such that mmdebstrap will abort with an appropriate error message very early on, correct?

Now suppose we do this, then doing so would make the following use-case impossible:

--customize-hook="mkdir ./bar" \
--customize-hook="sync-out /foo ./bar"

With your proposed changes, mmdebstrap abort early even though another hook is creating ./bar upfront.

I'm not sure in which way mmdebstrap could possibly do any checks here. Suppose somebody runs mmdebstrap with: --customize-hook="sync-out /foo ./bar" If I understand you correctly, then you would like mmdebstrap to check if `./bar` is even writable such that mmdebstrap will abort with an appropriate error message very early on, correct? Now suppose we do this, then doing so would make the following use-case impossible: --customize-hook="mkdir ./bar" \ --customize-hook="sync-out /foo ./bar" With your proposed changes, mmdebstrap abort early even though another hook is creating `./bar` upfront.

fepitre commented

2021-08-23 08:14:33 +00:00

Author

I'm not sure in which way mmdebstrap could possibly do any checks here. Suppose somebody runs mmdebstrap with:
--customize-hook="sync-out /foo ./bar"
If I understand you correctly, then you would like mmdebstrap to check if ./bar is even writable such that mmdebstrap will abort with an appropriate error message very early on, correct?

Yes.

Now suppose we do this, then doing so would make the following use-case impossible:
--customize-hook="mkdir ./bar" \
--customize-hook="sync-out /foo ./bar"
With your proposed changes, mmdebstrap abort early even though another hook is creating ./bar upfront.

Yes, I'm not sure how/if mmdebstrap should manage this.

> I'm not sure in which way mmdebstrap could possibly do any checks here. Suppose somebody runs mmdebstrap with: > > --customize-hook="sync-out /foo ./bar" > > If I understand you correctly, then you would like mmdebstrap to check if `./bar` is even writable such that mmdebstrap will abort with an appropriate error message very early on, correct? Yes. > Now suppose we do this, then doing so would make the following use-case impossible: > > --customize-hook="mkdir ./bar" \ > --customize-hook="sync-out /foo ./bar" > > With your proposed changes, mmdebstrap abort early even though another hook is creating `./bar` upfront. Yes, I'm not sure how/if mmdebstrap should manage this.

josch commented

2021-08-23 08:19:34 +00:00

Owner

Now suppose we do this, then doing so would make the following use-case impossible:
--customize-hook="mkdir ./bar" \
--customize-hook="sync-out /foo ./bar"
With your proposed changes, mmdebstrap abort early even though another hook is creating ./bar upfront.
Yes, I'm not sure how/if mmdebstrap should manage this.

I don't think you can. A series of --customize-hook options is equivalent to writing a shell script. But you are also not filing a bug against bash to ask it to first check all permissions before executing your script so that it fails early and not only after executing the line that ends up failing.

> > Now suppose we do this, then doing so would make the following use-case impossible: > > > > --customize-hook="mkdir ./bar" \ > > --customize-hook="sync-out /foo ./bar" > > > > With your proposed changes, mmdebstrap abort early even though another hook is creating `./bar` upfront. > > Yes, I'm not sure how/if mmdebstrap should manage this. I don't think you can. A series of `--customize-hook` options is equivalent to writing a shell script. But you are also not filing a bug against bash to ask it to first check all permissions before executing your script so that it fails early and not only after executing the line that ends up failing.

josch closed this issue

2021-12-06 10:25:07 +00:00

General permissions check before doing the build #11