Closed #1789 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1789#event-9719841415
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Fixed by f3eaeeb7341085e1850e914350cf1f33d538320d
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1789#issuecomment-1619931061
You are receiving this because you are subscribed to this thread.
Message ID:
It is, but it wont suppress the warning.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1789#issuecomment-934115490___
> It won't solve the issue though, as the group still doesn't exist when the
> files are created
But it is possible to chown by a numeric UID/GID, isn't it?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It won't solve the issue though, as the group still doesn't exist when the
files are created. Guess something like `echo "shadow:x:404:" >> /etc/group` in
%pre might do the trick.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
> Is lua in rpm able to call chown() without the chown utility from coreutils
> being present in the new chroot?
Ability to do stuff without external tools is the raison d'être for Lua in rpm.
Yes, there's posix.chown() in our Lua environment.
--
You are receiving this because you are
by the way, I am not sure that root:shadow owner of /etc/shadow makes sense,
Fedora uses just root:root
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> > Commit
> > [f9c7b53](https://github.com/rpm-software-management/rpm/commit/f9c7b53f50adc129baee809692d4c80b3bd15432)
> > is supposed to be a no-op, so if that is the thing changing behavior then
> > we need to look at it, I don't remember any intentional change to this
> > effect anyway.
> `chgrp` in the `%post` scriptlet should do the trick - although I admit it is
> not a great solution
Yeah, it is what I did, but in %posttrans, to lighten dependency graph. But the
warning from rpm is still present.
> I still have this vivid memory of rpm no longer using the the files from
> Commit
> [f9c7b53](https://github.com/rpm-software-management/rpm/commit/f9c7b53f50adc129baee809692d4c80b3bd15432)
> is supposed to be a no-op, so if that is the thing changing behavior then we
> need to look at it, I don't remember any intentional change to this effect
> anyway. That
Oh, right. The patch does only move the `rpmugInit` call to later. I first
thought it now does that whenever entering the chroot and was wondering why the
commit message is more vocal about that.
I still have this vivid memory of rpm no longer using the the files from
outside the chroot. But I
Commit f9c7b53 is supposed to be a no-op, so if that is the thing changing
behavior then we need to look at it, I don't remember any intentional change to
this effect anyway. That doesn't change the fact that rpm cannot bootstrap
user/group info, never could.
--
You are receiving this because
This is caused by RPM no longer using the user and group information from out
side of the change root. Earlier versions were not properly using the inside
files in all cases.
The uid and gid of these files are set before they are moved in place. So the
shadow group does not exist yet. While
13 matches
Mail list logo
