Re: su in debian.rules
(gee, it must be late, I didn't realize I'd written so much on this
issue... quick summary: I don't want to make anyone else build
packages differently, I just don't want to need root to do my own, and
I have some ideas about how to do that.)
> when you don't strictly need to be root, but I think you may be taking
> this to an extreme. ...
Oh, quite possibly. I am in the computer security field, and a lot of
things that I find perfectly reasonable tend to horrify traditional
system managers and users :-)
Nonetheless, I'm looking for an alternative to what the packages I
generate now do anyway: build unprivileged, generate tarfile
unprivileged, but include in it an install script that fixes
permissions and ownership, updates /etc/services, prompts for default
config file values... very much like a postinst script [in fact for
the cns4 package, the postinst script just runs my install script.]
I'll grant that it's more important for my tar-only releases to have
correct permissions in the tar file, since the user can't be forced to
run the install script, and the installation will "mostly work"
(especially if it is an upgrade) if they forget.
>Do feel free to solve this problem, but I would not want to be compelled
>to use your solution
Ooh, of course not... sorry if I made that implication...
>prefer a solution that makes building packages simpler, not more
The issue is that *I* consider, for *myself*, the need to become root
to build a package to be a *serious* impediment. At the same time, you
probably don't want to install packages from me that have my local uid
in them -- it's probably even a violation of the guidelines for the
package to have my uid owning the files, and it is unarguably a Bad
Idea.
I'm not saying that the current implementation isn't ok for other
people; it's certainly a lot easier, especially for secondary
packages, to just get the perms from a successful make install. I just
want an alternative. In fact, it would be enough, for me, to change
dpkg-deb to have an option to read a tar file directly, instead of
getting the package out of a filesystem tree; then I could do my own
processing on a tar file (consider, even, an "install" program that
wrote directly to a tarfile!) and hand it off. (A simple change to
build.c, it looks like, I'll try it this weekend.)
> than the status quo, and present their own new security problems. I'd
I'm curious, especially if you've had the patience to read this far :-)
what new security problems you find in my approach. You mentioned one:
* it's harder to keep the package up-to-date with upstream
permission changes
> that appear to have been written by a privileged user, and will indeed
> become privileged when they are extracted. OK, I admit that any user
Umm, I find that a drastic over-interpretation of tar format :-) I
would agree that a given uid/gid in a tar file is an indication of
what it is *suggested* you unpack it as, but with no implication of
what it might once have actually been. There is *no* trust
relationship involved here...
Frankly, tar should have a similar output mapping feature (or optional
interactive callouts, "do you really want foo owned by root? do you
really want foo mode 4755?") but I don't have time to design it...
_Mark_ <eichin@cygnus.com>
Cygnus Support, Eastern USA
Reply to: