this email is to serve as a notification of a problem and a survey of
possible workarounds/solutions.
the problem: when using dpkg to upgrade a package that contains setuid/gid
files which have been unified/hashified, dpkg wants to first chmod 600 the
files before unlinking them (in case somebody has hardlinked to a security
susceptible file which will remain even after the upgrade because of the
hardlink). of course, as the files are immutable, the chmod fails, but
this behavior is never seen for all other files because dpkg unlinks them
without chmoding them first (and unlinking is allowed).
the problem exhibits itself as such:
dpkg: error processing /var/cache/apt/archives/passwd_1%3a4.0.3-31sarge8_amd64.deb (--unpack):
failed to rmdir/unlink `//usr/bin/chage.dpkg-tmp': Operation not permitted
the relevant line in an strace:
6516 chmod("//usr/bin/chage.dpkg-tmp", 0600) = -1 EPERM (Operation not permitted)
sam vilain brought up this issue 4 years ago in
http://lists.debian.org/debian-dpkg/2002/06/msg00105.html.
more recently i think "sebd" encountered this problem and shared it with
herbert in irc, recorded in
http://irc.13thfloor.at/LOG/2005-03/LOG_2005-03-19.txt.
this is especially problematic because currently dpkg emits an error,
aborts the upgrade, and returns a non-zero exit status, but lists the new
package version as being installed without error (though none of the new
files were installed). i reported this bug at
http://bugs.debian.org/382760.
one solution is to manually remove all setuid/gid files before upgrading
them (which i did before tonight when i would have had to do that for a
dozen files on 14 vservers due to upgrading login & passwd packages; that
crossed my threshold). but that still doesn't deal with the security
implication brought up by ben collins in response to sam vilain's email.
that's not a major concern for me because currently i only use vservers as
personal per-process super chroot's, so if somebody besides me is
creating hardlinks to setuid files, and believe me i'm not, then i already
have bigger security problems. but if i should ever want to provide
semi-public user-level access to my vservers, then what are my options?
how do other distros address this problem, or do they ignore it or are
unaware of it?
i'm currently implementing the workaround as a patch to dpkg disabling the
chmod. that's good enough security-wise for my particular need. it means
i'll have to maintain the patch against dpkg and build a new package
every time dpkg is updated, but i run stable (currently "sarge") on my
server and in my vservers, so it shouldn't happen that frequently. i
thought about writing a wrapper around dpkg, but that would be fairly
complex as dpkg accepts a lot of different options that i would have to
take into consideration and i would have to insure the unique interaction
between apt-get and dpkg didn't break.
so what are other people doing to work around this problem? is this not an
issue for anybody else because i'm the only debian user with
unified/hashified vservers?
corey
-- undefined@pobox.com _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserverReceived on Sun Aug 13 09:41:59 2006