Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
17 views
Skip to first unread message
Christian Kastner
Jan 28, 2015, 6:10:02 PM1/28/15
to
Control: tags -1 + patch
On Sat, 24 Jan 2015 12:05:52 +0100 Andreas Beckmann <an...@debian.org> wrote:
> The upgrade to jessie with sudo-ldap/jessie went smooth, and thereafter
> I wanted to switch to sudo/jessie, which failed due to missing
> /etc/sudoers, the problem is reproducible in plain jessie, too:
>
> # apt-get install sudo
<snip>
> WARNING: /etc/sudoers not present!
> chown: cannot access '/etc/sudoers': No such file or directory
> dpkg: error processing package sudo (--configure):
> subprocess installed post-installation script returned error exit status 1
> Errors were encountered while processing:
> sudo
> E: Sub-process /usr/bin/dpkg returned an error code (1)
The problem stems from the solution used to avoid an unnecessary action
prompt for a conffile change when in fact there was no change. See bugs
#636049, #612532, #660594.
1. Each respective preinst checks, via md5sum, if /etc/sudoers has
changed. Iff not, it is moved to a temporary location at
/etc/sudoers.pre-conffile.
2. Each respective postinst checks whether /etc/sudoers is present,
and warns if it isn't (see WARNING quoted above).
3. Then follows an unconditional chown of /etc/sudoers, and when this
fails, postinst aborts because of set -e.
This is the first problem. It is of course possible for this file to be
generally absent (it's a conffile, and the user might have forcefully
removed it), so this chown should be guarded by a test for existence.
3. Later on, there is an attempted to remove the temporarily
renamed /etc/sudoers.pre-conffile mentioned above:
> # if we've gotten this far .. remove the saved, unchanged old sudoers file
> rm -f /etc/sudoers.pre-conffile
This I don't understand. Why remove it? This file can only exist because
of step 1. above, and if it exists, the purpose was to just temporarily
move it out of the way to avoid a conffile-change question. Why is it
being removed now? Shouldn't it just be moved back in step 2.?
Please find attached a debdiff against the version in t-p-u that
A. Makes the chmod/chown conditional on the existence of /etc/sudoers
B. When /etc/sudoers.pre-conffile exists, moves it back to
/etc/sudoers. This is done unconditionally since the very
existence of /etc/sudoers.pre-conffile implies that it is the
pristine package version (recall the md5sum check above). So
the user did not delete or change /etc/sudoers, and we want it
back.
I'm confident that change A. is correct and necessary, but change B.
depends on whether I understood the problem the code is trying to solve
correctly!
I tested this with various combinations (pristine, changed, deleted
/etc/sudoers), and TTBOMYK the result is policy-conform. Additional
testing would be highly appreciated, though.
Regards,
Christian
On Sat, 24 Jan 2015 12:05:52 +0100 Andreas Beckmann <an...@debian.org> wrote:
> The upgrade to jessie with sudo-ldap/jessie went smooth, and thereafter
> I wanted to switch to sudo/jessie, which failed due to missing
> /etc/sudoers, the problem is reproducible in plain jessie, too:
>
> # apt-get install sudo
<snip>
> WARNING: /etc/sudoers not present!
> chown: cannot access '/etc/sudoers': No such file or directory
> dpkg: error processing package sudo (--configure):
> subprocess installed post-installation script returned error exit status 1
> Errors were encountered while processing:
> sudo
> E: Sub-process /usr/bin/dpkg returned an error code (1)
The problem stems from the solution used to avoid an unnecessary action
prompt for a conffile change when in fact there was no change. See bugs
#636049, #612532, #660594.
1. Each respective preinst checks, via md5sum, if /etc/sudoers has
changed. Iff not, it is moved to a temporary location at
/etc/sudoers.pre-conffile.
2. Each respective postinst checks whether /etc/sudoers is present,
and warns if it isn't (see WARNING quoted above).
3. Then follows an unconditional chown of /etc/sudoers, and when this
fails, postinst aborts because of set -e.
This is the first problem. It is of course possible for this file to be
generally absent (it's a conffile, and the user might have forcefully
removed it), so this chown should be guarded by a test for existence.
3. Later on, there is an attempted to remove the temporarily
renamed /etc/sudoers.pre-conffile mentioned above:
> # if we've gotten this far .. remove the saved, unchanged old sudoers file
> rm -f /etc/sudoers.pre-conffile
This I don't understand. Why remove it? This file can only exist because
of step 1. above, and if it exists, the purpose was to just temporarily
move it out of the way to avoid a conffile-change question. Why is it
being removed now? Shouldn't it just be moved back in step 2.?
Please find attached a debdiff against the version in t-p-u that
A. Makes the chmod/chown conditional on the existence of /etc/sudoers
B. When /etc/sudoers.pre-conffile exists, moves it back to
/etc/sudoers. This is done unconditionally since the very
existence of /etc/sudoers.pre-conffile implies that it is the
pristine package version (recall the md5sum check above). So
the user did not delete or change /etc/sudoers, and we want it
back.
I'm confident that change A. is correct and necessary, but change B.
depends on whether I understood the problem the code is trying to solve
correctly!
I tested this with various combinations (pristine, changed, deleted
/etc/sudoers), and TTBOMYK the result is policy-conform. Additional
testing would be highly appreciated, though.
Regards,
Christian
Andreas Beckmann
Jan 29, 2015, 3:40:02 AM1/29/15
to
Hi Christian,
thanks for looking into this.
What we have here is a conffile shared between two packages that
Conflicts+Replaces each other. That's even more weird than placing
conffiles in multi-arch:same packages ... at least they don't ship
different versions (but they did in lenny ...)
I think the conffiles part should be factored out to a separate package
(e.g. "sudoers"). But probably not for jessie :-)
If I see this correctly, in wheezy /etc/sudoers finally became a
conffile. So the preinst scripts are wrong - they should not touch (or
move around) the unmodified wheezy conffile.
And while switching sudo->sudo-ldap the following happens:
sudo gets removed, conffile remains
sudo-ldap.preinst gets called with no previous version, so the conffile
handling is activated - the md5sum matches that one from wheezy and
therefore /etc/sudoers is moved aside
sudo-ldap replaces sudo and takes over a deleted conffile
this is not reinstated - per policy
sudo-ldap.postinst explodes on the deleted conffile.
could you try how switching between sudo and sudo-ldap works if the
wheezy md5sum is removed from teh preinst?
Andreas
Is sudo useful at all if /etc/sudoers is missing?
> 3. Later on, there is an attempted to remove the temporarily
> renamed /etc/sudoers.pre-conffile mentioned above:
>
>> # if we've gotten this far .. remove the saved, unchanged old sudoers file
>> rm -f /etc/sudoers.pre-conffile
that is an *old* pristine sudoer that was not a conffile
> This I don't understand. Why remove it? This file can only exist because
> of step 1. above, and if it exists, the purpose was to just temporarily
> move it out of the way to avoid a conffile-change question. Why is it
> being removed now? Shouldn't it just be moved back in step 2.?
dpkg should have installed a new sudoers (that is now a conffile)
the .pre-conffile is a backup that should be restored in failed-upgrade
or removed in postinst, so the intention is right, just the preinst
should not have touch a conffile
> Please find attached a debdiff against the version in t-p-u that
>
> A. Makes the chmod/chown conditional on the existence of /etc/sudoers
maybe its better to explode here if sudoers does not exist - I assume
sudo will be nonfunctional without it
> B. When /etc/sudoers.pre-conffile exists, moves it back to
> /etc/sudoers. This is done unconditionally since the very
> existence of /etc/sudoers.pre-conffile implies that it is the
> pristine package version (recall the md5sum check above). So
> the user did not delete or change /etc/sudoers, and we want it
> back.
there was never the intention to restore this in a pre-conffile to
conffile upgrade case ...
> I'm confident that change A. is correct and necessary, but change B.
> depends on whether I understood the problem the code is trying to solve
> correctly!
>
> I tested this with various combinations (pristine, changed, deleted
> /etc/sudoers), and TTBOMYK the result is policy-conform. Additional
> testing would be highly appreciated, though.
>
> Regards,
> Christian
>
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
thanks for looking into this.
What we have here is a conffile shared between two packages that
Conflicts+Replaces each other. That's even more weird than placing
conffiles in multi-arch:same packages ... at least they don't ship
different versions (but they did in lenny ...)
I think the conffiles part should be factored out to a separate package
(e.g. "sudoers"). But probably not for jessie :-)
If I see this correctly, in wheezy /etc/sudoers finally became a
conffile. So the preinst scripts are wrong - they should not touch (or
move around) the unmodified wheezy conffile.
And while switching sudo->sudo-ldap the following happens:
sudo gets removed, conffile remains
sudo-ldap.preinst gets called with no previous version, so the conffile
handling is activated - the md5sum matches that one from wheezy and
therefore /etc/sudoers is moved aside
sudo-ldap replaces sudo and takes over a deleted conffile
this is not reinstated - per policy
sudo-ldap.postinst explodes on the deleted conffile.
could you try how switching between sudo and sudo-ldap works if the
wheezy md5sum is removed from teh preinst?
Andreas
> 3. Later on, there is an attempted to remove the temporarily
> renamed /etc/sudoers.pre-conffile mentioned above:
>
>> # if we've gotten this far .. remove the saved, unchanged old sudoers file
>> rm -f /etc/sudoers.pre-conffile
> This I don't understand. Why remove it? This file can only exist because
> of step 1. above, and if it exists, the purpose was to just temporarily
> move it out of the way to avoid a conffile-change question. Why is it
> being removed now? Shouldn't it just be moved back in step 2.?
the .pre-conffile is a backup that should be restored in failed-upgrade
or removed in postinst, so the intention is right, just the preinst
should not have touch a conffile
> Please find attached a debdiff against the version in t-p-u that
>
> A. Makes the chmod/chown conditional on the existence of /etc/sudoers
sudo will be nonfunctional without it
> B. When /etc/sudoers.pre-conffile exists, moves it back to
> /etc/sudoers. This is done unconditionally since the very
> existence of /etc/sudoers.pre-conffile implies that it is the
> pristine package version (recall the md5sum check above). So
> the user did not delete or change /etc/sudoers, and we want it
> back.
conffile upgrade case ...
> I'm confident that change A. is correct and necessary, but change B.
> depends on whether I understood the problem the code is trying to solve
> correctly!
>
> I tested this with various combinations (pristine, changed, deleted
> /etc/sudoers), and TTBOMYK the result is policy-conform. Additional
> testing would be highly appreciated, though.
>
> Regards,
> Christian
>
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Beckmann
Jan 29, 2015, 3:30:04 PM1/29/15
to
just to make notation clear
/etc/sudoers is a *configuration file*, i.e. rules of preserving user
changes apply
since wheezy it is also a *conffile* i.e. shipped with the package at
/etc/sudoers and managed by dpkg, not to be touched by maintainer scripts
before it was managed by maintainer scripts
the tricky part is to get a smooth upgrade patch from the pre-conffile
stage to a conffile
* with preserving user chnages
* without asking useles questions
(do not even think about downgrades, they are just unsuported)
I think the real bug is still that pre-conffile handling is applied to a
conffile by listing the wheezy md5sum
if dpkg installs a conffile for the first time there are three
possibilities:
* the file does not exist - trivial: install and record it
* the file exists and is the same as being installed - record it
* the file exists but is different: ask
Andreas
/etc/sudoers is a *configuration file*, i.e. rules of preserving user
changes apply
since wheezy it is also a *conffile* i.e. shipped with the package at
/etc/sudoers and managed by dpkg, not to be touched by maintainer scripts
before it was managed by maintainer scripts
the tricky part is to get a smooth upgrade patch from the pre-conffile
stage to a conffile
* with preserving user chnages
* without asking useles questions
(do not even think about downgrades, they are just unsuported)
I think the real bug is still that pre-conffile handling is applied to a
conffile by listing the wheezy md5sum
if dpkg installs a conffile for the first time there are three
possibilities:
* the file does not exist - trivial: install and record it
* the file exists and is the same as being installed - record it
* the file exists but is different: ask
Andreas
Andreas Beckmann
Jan 29, 2015, 6:30:02 PM1/29/15
to
On 2015-01-29 23:16, Christian Kastner wrote:
> True. But as you observed in your initial report, the same bug can be
> triggered in a clean jessie environment, where the configuration file /
> conffile distinction is not a factor.
probably because the md5sums for wheezy and jessie are the same
> But that is all beside the point, because the conffile is not being
> installed for the first time.
That works fine. sudo installs its conffile
> The problem manifests itself during a
> switch, so we have a pre-existing conffile.
Which is erroneously moved aside by sudo-ldap.preinst, thereafter dpkg
unpacks sudo-ldap, takes over file ownership (incl. conffiles) from sudo
and once it gets around to installing ist conffile it notices that this
has not changed from the known md5sum, so no attempt is made to
"upgrade" the missing conffile.
> True. But as you observed in your initial report, the same bug can be
> triggered in a clean jessie environment, where the configuration file /
> conffile distinction is not a factor.
probably because the md5sums for wheezy and jessie are the same
> But that is all beside the point, because the conffile is not being
> installed for the first time.
That works fine. sudo installs its conffile
> The problem manifests itself during a
> switch, so we have a pre-existing conffile.
Which is erroneously moved aside by sudo-ldap.preinst, thereafter dpkg
unpacks sudo-ldap, takes over file ownership (incl. conffiles) from sudo
and once it gets around to installing ist conffile it notices that this
has not changed from the known md5sum, so no attempt is made to
"upgrade" the missing conffile.
Christian Kastner
Feb 18, 2015, 1:40:04 PM2/18/15
to
Hi,
On 2015-02-07 01:02, Christian Kastner wrote:
> I've looked into this now, and I believe that the --compare-versions
> issue and the chown/chmod issue is all there is to this bug. I have
> attached a new debdiff (v2) with fixes for both.
>
> I have tested this patch in a number of combinations, including (but not
> limited to):
>
> sudo (squeeze) -> sudo (jessie) upgrade
> sudo-ldap (squeeze) -> sudo-ldap (jessie) upgrade
>
> Works as intended. An unchanged /etc/sudoers gets replaced with the new
> version, a changed sudoers will cause the user to be asked what to do.
>
> sudo (jessie) -> sudo (jessie+deb8u2) upgrade
> sudo-ldap (jessie) -> sudo-ldap (jessie+deb8u2) upgrade
>
> Same result as in the previous case.
>
> sudo (jessie+deb8u2) -> sudo-ldap (jessie+deb8u2) switch
> sudo-ldap (jessie+deb8u2) -> sudo (jessie+deb8u2) switch
>
> /etc/sudoers always gets carried over. There is no scenario where the
> user might have to be asked, as the package versions (and the sudoers
> they supply) are identical, and the user's changed version therefore
> trumps the default version.
did anyone get the chance to confirm my results yet?
Bdale, once such a confirmation (or another fix) is in, how would you
like to proceed? I could help with the RT communication again
Regards,
Christian
On 2015-02-07 01:02, Christian Kastner wrote:
> I've looked into this now, and I believe that the --compare-versions
> issue and the chown/chmod issue is all there is to this bug. I have
> attached a new debdiff (v2) with fixes for both.
>
> I have tested this patch in a number of combinations, including (but not
> limited to):
>
> sudo (squeeze) -> sudo (jessie) upgrade
> sudo-ldap (squeeze) -> sudo-ldap (jessie) upgrade
>
> Works as intended. An unchanged /etc/sudoers gets replaced with the new
> version, a changed sudoers will cause the user to be asked what to do.
>
> sudo (jessie) -> sudo (jessie+deb8u2) upgrade
> sudo-ldap (jessie) -> sudo-ldap (jessie+deb8u2) upgrade
>
> Same result as in the previous case.
>
> sudo (jessie+deb8u2) -> sudo-ldap (jessie+deb8u2) switch
> sudo-ldap (jessie+deb8u2) -> sudo (jessie+deb8u2) switch
>
> /etc/sudoers always gets carried over. There is no scenario where the
> user might have to be asked, as the package versions (and the sudoers
> they supply) are identical, and the user's changed version therefore
> trumps the default version.
did anyone get the chance to confirm my results yet?
Bdale, once such a confirmation (or another fix) is in, how would you
like to proceed? I could help with the RT communication again
Regards,
Christian
Michael Gilbert
Feb 22, 2015, 1:50:03 AM2/22/15
to
On Sat, Feb 21, 2015 at 9:52 PM, Christian Kastner wrote:
> It's not backed up in jessie or later. The backup/md5sum stuff is
> preceeded by a test for and old version less than "1.7.4p4-4", so in
> wheezy and later, all the md5sum stuff is ignored during upgrades.
It is most certainly backed up in jessie or later. That happens
during "install" rather than "upgrade", which you describe below
anyway.
> However, the backup code is accidentally triggered when switching
> between sudo and sudo-ldap, because switching is not upgrading (in the
> dpkg sense), and the version test above does not account for this scenario:
>
> <preinst>
> $ dpkg --compare-versions "" le "1.7.4p4-4" && echo oops
> oops
>
>> The solution I propose to modify /etc/sudoers so that it has a
>> different checksum, which prevents the incorrect backup. Please see
>> attached
>
> This has one nasty side effect: when upgrading from wheezy to jessie,
> anyone with a changed /etc/sudoers will be asked a conffile question,
> because both the local and the maintainer's version changed.
That is true for conffiles in general, but will not be the case for
sudo because its *.preinst moves /etc/sudoers for lenny/squeeze/wheezy
out of the way to /etc/sudoers.pre-conffile.
> Modifying sudoers so that it has a checksum can't be right, because the
> code where the checksum is relevant shouldn't have been reached in the
> first place (in wheezy or later).
It is possible that the user removed the package, then installed it
later. That is why the "install" path also has handling for old
/etc/sudoers, to perform backup in that case also.
> Fixing the --compare-versions above does precisely that -- the md5sum
> stuff is never even reached.
With that approach the check is now not reached in cases where it should.
Best wishes,
Mike
> It's not backed up in jessie or later. The backup/md5sum stuff is
> preceeded by a test for and old version less than "1.7.4p4-4", so in
> wheezy and later, all the md5sum stuff is ignored during upgrades.
It is most certainly backed up in jessie or later. That happens
during "install" rather than "upgrade", which you describe below
anyway.
> However, the backup code is accidentally triggered when switching
> between sudo and sudo-ldap, because switching is not upgrading (in the
> dpkg sense), and the version test above does not account for this scenario:
>
> <preinst>
> $ dpkg --compare-versions "" le "1.7.4p4-4" && echo oops
> oops
>
>> The solution I propose to modify /etc/sudoers so that it has a
>> different checksum, which prevents the incorrect backup. Please see
>> attached
>
> This has one nasty side effect: when upgrading from wheezy to jessie,
> anyone with a changed /etc/sudoers will be asked a conffile question,
> because both the local and the maintainer's version changed.
That is true for conffiles in general, but will not be the case for
sudo because its *.preinst moves /etc/sudoers for lenny/squeeze/wheezy
out of the way to /etc/sudoers.pre-conffile.
> Modifying sudoers so that it has a checksum can't be right, because the
> code where the checksum is relevant shouldn't have been reached in the
> first place (in wheezy or later).
It is possible that the user removed the package, then installed it
later. That is why the "install" path also has handling for old
/etc/sudoers, to perform backup in that case also.
> Fixing the --compare-versions above does precisely that -- the md5sum
> stuff is never even reached.
With that approach the check is now not reached in cases where it should.
Best wishes,
Mike
Christian Kastner
Feb 22, 2015, 6:40:02 AM2/22/15
to
On 2015-02-22 07:43, Michael Gilbert wrote:
> On Sat, Feb 21, 2015 at 9:52 PM, Christian Kastner wrote:
>> It's not backed up in jessie or later. The backup/md5sum stuff is
>> preceeded by a test for and old version less than "1.7.4p4-4", so in
>> wheezy and later, all the md5sum stuff is ignored during upgrades.
>
> It is most certainly backed up in jessie or later. That happens
> during "install" rather than "upgrade", which you describe below
> anyway.
That's why I said "during upgrades" here.
> On Sat, Feb 21, 2015 at 9:52 PM, Christian Kastner wrote:
>> It's not backed up in jessie or later. The backup/md5sum stuff is
>> preceeded by a test for and old version less than "1.7.4p4-4", so in
>> wheezy and later, all the md5sum stuff is ignored during upgrades.
>
> It is most certainly backed up in jessie or later. That happens
> during "install" rather than "upgrade", which you describe below
> anyway.
>> However, the backup code is accidentally triggered when switching
>> between sudo and sudo-ldap, because switching is not upgrading (in the
>> dpkg sense), and the version test above does not account for this scenario:
>>
>> <preinst>
>> $ dpkg --compare-versions "" le "1.7.4p4-4" && echo oops
>> oops
>>
>>> The solution I propose to modify /etc/sudoers so that it has a
>>> different checksum, which prevents the incorrect backup. Please see
>>> attached
>>
>> This has one nasty side effect: when upgrading from wheezy to jessie,
>> anyone with a changed /etc/sudoers will be asked a conffile question,
>> because both the local and the maintainer's version changed.
>
> That is true for conffiles in general, but will not be the case for
> sudo because its *.preinst moves /etc/sudoers for lenny/squeeze/wheezy
> out of the way to /etc/sudoers.pre-conffile.
package maintainer's versions, so when user did _not_ change /etc/sudoers.
If the user changed /etc/sudoers, the the md5sum no longer matches, ergo
no move. Then local and maintainer version divert from the previous
maintainer version, and a conffile question has to be asked.
I just verified this by upgrading from a deb8u1 jessie version, with a
changed /etc/sudoers, to your proposed version. I was asked what to do.
>> Modifying sudoers so that it has a checksum can't be right, because the
>> code where the checksum is relevant shouldn't have been reached in the
>> first place (in wheezy or later).
>
> It is possible that the user removed the package, then installed it
> later.
entirely for dpkg to handle, not for the *.preinst scripts. Anything in
the *.preinst is exclusively for when upgrading from squeeze.
The <= 1.7.4p4-4 check is meant to ensure that, but it's buggy as it
does not handle the "install" case properly. This needs to be fixed
regardless.
My argument is that this is also what's causing the bug we are
discussing right now.
>> Fixing the --compare-versions above does precisely that -- the md5sum
>> stuff is never even reached.
>
> With that approach the check is now not reached in cases where it should.
incomplete.
Regards,
Christian
Michael Gilbert
Feb 22, 2015, 12:00:03 PM2/22/15
to
On Sun, Feb 22, 2015 at 6:35 AM, Christian Kastner wrote:
> In wheezy and later, where /etc/sudoers already is a conffile, that is
> entirely for dpkg to handle, not for the *.preinst scripts. Anything in
> the *.preinst is exclusively for when upgrading from squeeze.
So, the more I think about it, isn't this the real problem? The
> In wheezy and later, where /etc/sudoers already is a conffile, that is
> entirely for dpkg to handle, not for the *.preinst scripts. Anything in
> the *.preinst is exclusively for when upgrading from squeeze.
*.preinst scripts mess with wheezy's /etc/sudoers even though it
should only be managed by dpkg.
Best wishes,
Mike
0 new messages