Re: [Reproducible-builds] symlink permission bits on non-Linux

[Guillem Jover]

[ Just stumbled on this on the mail archive. ]

Hi!

On Tue, 2016-02-16 at 08:42:07 +0100, Jérémy Bobbio wrote:
> Steven Chamberlain:
> > On linux, a symlink can only have permissions 0777 (lrwxrwxrwx)
> > 
> > But on at least kfreebsd (maybe hurd?) there is no such limitation, and
> > permissions are set like any regular file.  That also means the umask is
> > applied...  and tar and dpkg-deb preserve this.

Yes, Hurd too. Linux probably is the odd one here.

> > This proves to be an issue for:
> >   * reproducible builds on kfreebsd, affected by user's umask
> >   * reproducing arch:all packages between linux<->kfreebsd
> >   * reproducing linux packages by cross-building from kfreebsd
> > 
> > I think we should normalise symlinks' permissions to 0777, except GNU
> > chmod can't do that!  (chmod follows the symlink, and has no -h flag).
> > 
> > Adding a -h (no dereference) option to chmod would allow dh_fixperms to
> > use that.  But (as pointed out in #759886) adding things there does not
> > help packages not using debhelper, or other uses of tar.
> > 
> > Would this be best added as a feature to tar, that dpkg-deb can use?
> > Probably a new flag, that would apply --mode a=rwx only to symlinks.
> > 
> > Or are there other ideas how to fix this?

I noticed this due to the dpkg test suite, and fixed it by temporarily
setting umask to 0:

  


And added it to the wiki:

  
.

> One idea floating is to get dpkg-deb working with an explicit manifest
> to create the package content. I believe that would solve the issue. But
> that's at least mid-term because dpkg needs to get its own Tar
> implementation (or maybe depend on libarchive) and, likely harder, a
> format needs to be defined for the manifest.

Right.

> In the meantime, shouldn't GNU chmod get a `-h` option in any cases if
> it's going to be used on kFreeBSD?
> 
> Then it's pretty easy to start with `dh_fixperms` and see how much it
> helps.
> 
> Guillem said he was ok with dpkg depending on recent versions of
> Tar[1], but changes would need to be accepted by Tar upstream.

Yes, if you get a new option in tar I'm fine using it. But given the
reaction to the --clamp-mtime option, this might not fly with upstream?
(Also it seems the patch for that one might have been better sent to
bug-tar instead of help-tar.)

> What's the situation regarding symlinks on HURD?

See above.

>  [1]:?https://bugs.debian.org/759886#73

Thanks,
Guillem

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] symlink permission bits on non-Linux

[Steven Chamberlain]

Hi,

On linux, a symlink can only have permissions 0777 (lrwxrwxrwx)

But on at least kfreebsd (maybe hurd?) there is no such limitation, and
permissions are set like any regular file.  That also means the umask is
applied...  and tar and dpkg-deb preserve this.

This proves to be an issue for:
  * reproducible builds on kfreebsd, affected by user's umask
  * reproducing arch:all packages between linux<->kfreebsd
  * reproducing linux packages by cross-building from kfreebsd

I think we should normalise symlinks' permissions to 0777, except GNU
chmod can't do that!  (chmod follows the symlink, and has no -h flag).

Adding a -h (no dereference) option to chmod would allow dh_fixperms to
use that.  But (as pointed out in #759886) adding things there does not
help packages not using debhelper, or other uses of tar.

Would this be best added as a feature to tar, that dpkg-deb can use?
Probably a new flag, that would apply --mode a=rwx only to symlinks.

Or are there other ideas how to fix this?

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds