Something that I do like in Slackware is that the build scripts to generate
Slackware packages assume that they will be run as root. Moreover the tool
buildpkg does not allow to set the correct owner of the files in a package
without doing a chown on the to-be-packaged directory (which requires to be
root); making impossible to make a build script which is able to generate a
package without being root. Making a package as root can be very dangerous
since we do a make install; maybe not with the official build scripts
(which are well tested) but well with home-made or hacked build scripts.

This approach contradicts the philosophy of never being root when you do not
really need to.

That's said, Slackware is still my preferred distro; but that does not
prevent me to point out some negative points ...


--
Olive

On Tue, 25 Jan 2005 00:03:31 +0100, olive.lin@versateladsl.be wrote:

> since we do a make install; maybe not with the official build scripts
> (which are well tested) but well with home-made or hacked build scripts.
>
> This approach contradicts the philosophy of never being root when you do not
> really need to.

I have had this discussion with Pat before; it's simply a more tried
and tested way to build packages for Slackware -- as root.

However, you could download fakeroot:
http://www.interlude.org.uk/unix/slackware

Build the package from the source I provide and in your script, do:

../configure
blah
make blah

fakeroot
chown -R root:bin blah
makepkg blah

You could also use slacktrack in combination with fakeroot (if you have it installed)
with its --froot option.

--
www.armedslack.org
| "Washing machines live longer with Calgon"

Olive wrote:
> Something that I do like in Slackware is that the build scripts to generate

s/do/don't/

> Slackware packages assume that they will be run as root. Moreover the tool
> buildpkg does not allow to set the correct owner of the files in a package

s/buildpkg/makepkg/ i assume?

> without doing a chown on the to-be-packaged directory (which requires to be
> root);

no, it's not makepkg that doesn't allow you to do this, it's linux that
doesn't allow you to do this. it'd be a great thing if every user could
create a file and then change ownership of it to root. /not/.

> This approach contradicts the philosophy of never being root when you do not
> really need to.

no, it doesn't, because you really *do* need to be root in order to make a
package that has to be installed system-wide. why? because tar retains
ownership and permissions of files. if you were to create a package as user
and then install it as root system-wide, the files *and* the directories in
the package would obtain ownership and permissions of the user that created
the package.

now, note that if a tar ball (and therefore also in a slackware package)
contains a file /usr/bin/someprog, it will also list the directories /usr
and /usr/bin. so if you were to install a package that was created by a
user system-wide, the directories /usr and /usr/bin would get ownership of
the user. as a result, those directories would be *writable* for that
user. which is not what you want.

> That's said, Slackware is still my preferred distro; but that does not
> prevent me to point out some negative points ...

well, i hope i have convinced you that it is not a negative point, but that
it is inevitable to do it this way: a package that's to be installed
system-wide must be created as root, because its directories and files must
be owned by root.

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Joost Kremers wrote:

>> This approach contradicts the philosophy of never being root when you do
>> not really need to.
>
> no, it doesn't, because you really *do* need to be root in order to make a
> package that has to be installed system-wide. why? because tar retains
> ownership and permissions of files. if you were to create a package as
> user and then install it as root system-wide, the files *and* the
> directories in the package would obtain ownership and permissions of the
> user that created the package.
>
> now, note that if a tar ball (and therefore also in a slackware package)
> contains a file /usr/bin/someprog, it will also list the directories /usr
> and /usr/bin. so if you were to install a package that was created by a
> user system-wide, the directories /usr and /usr/bin would get ownership of
> the user. as a result, those directories would be *writable* for that
> user. which is not what you want.

That's why (among other reasons) the post-install script idea was invented.

pkot
--
p k o t a t b e z s e n s u d o t p l
http://www.gnokii.org/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Olive dared to utter,
> Something that I do like in Slackware is that the build scripts to generate
> Slackware packages assume that they will be run as root. Moreover the tool
> buildpkg does not allow to set the correct owner of the files in a package
> without doing a chown on the to-be-packaged directory (which requires to be
> root); making impossible to make a build script which is able to generate a
> package without being root. Making a package as root can be very dangerous
> since we do a make install; maybe not with the official build scripts
> (which are well tested) but well with home-made or hacked build scripts.
>
> This approach contradicts the philosophy of never being root when you do not
> really need to.

Not exactly, as you do really need to be root to create a package,
regardless of package type.[0] "make install" generally has to be run
as root for anything that is going to be installed system-wide. Users
are not able to chown their files to owner root for example. You could
say that it is more secure to run the compile as a user, and to that I
agree. However, I think you miss the point that a compile-time-based
attack is highly unlikely, if only because it is no less difficult than
implimenting a flaw in the resulting binary (and less likely to
actually work). Hence you should only be using trusted source anyway.
If you don't trust your source, don't trust that compiling it as a user
is going to some how magically make you safe.

[0] Note that this isn't _exactly_ true, but that discussion is for
another post. :^)

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9ZaNlKR45I6cfKARAjVvAJ9nRg2pfErmY1C32o71jK kQ9TQTnACgi2Xs
wvVu/fpHZeQ49LSLueny54Q=
=szcj
-----END PGP SIGNATURE-----

Joost Kremers wrote:

> Olive wrote:
>> Something that I do like in Slackware is that the build scripts to
>> generate
>
> s/do/don't/
>
>> Slackware packages assume that they will be run as root. Moreover the
>> tool buildpkg does not allow to set the correct owner of the files in a
>> package
>
> s/buildpkg/makepkg/ i assume?
>
>> without doing a chown on the to-be-packaged directory (which requires to
>> be root);
>
> no, it's not makepkg that doesn't allow you to do this, it's linux that
> doesn't allow you to do this. it'd be a great thing if every user could
> create a file and then change ownership of it to root. /not/.
>
>> This approach contradicts the philosophy of never being root when you do
>> not really need to.
>
> no, it doesn't, because you really *do* need to be root in order to make a
> package that has to be installed system-wide. why? because tar retains
> ownership and permissions of files. if you were to create a package as
> user and then install it as root system-wide, the files *and* the
> directories in the package would obtain ownership and permissions of the
> user that created the package.
>
> now, note that if a tar ball (and therefore also in a slackware package)
> contains a file /usr/bin/someprog, it will also list the directories /usr
> and /usr/bin. so if you were to install a package that was created by a
> user system-wide, the directories /usr and /usr/bin would get ownership of
> the user. as a result, those directories would be *writable* for that
> user. which is not what you want.
>
>> That's said, Slackware is still my preferred distro; but that does not
>> prevent me to point out some negative points ...
>
> well, i hope i have convinced you that it is not a negative point, but
> that it is inevitable to do it this way: a package that's to be installed
> system-wide must be created as root, because its directories and files
> must be owned by root.
>

The answer of Suart Winter shows precisely that such thing is possible with
the provided Slackware scripts and I thank him very much for the info!

You mistake the fact that the kernel does not allow to change the ownership
of a file (which is expected) and the possibility for a normal user to
create a tar archive where the files has whatever owner recorded. Tar does
indeed support to reset all ownership to the desired values (with the
--group and --owner option) in a limited way.

--
Olive

Stuart Winter wrote:

> On Tue, 25 Jan 2005 00:03:31 +0100, olive.lin@versateladsl.be wrote:
>
>> since we do a make install; maybe not with the official build scripts
>> (which are well tested) but well with home-made or hacked build scripts.
>>
>> This approach contradicts the philosophy of never being root when you do
>> not really need to.
>
> I have had this discussion with Pat before; it's simply a more tried
> and tested way to build packages for Slackware -- as root.
>
> However, you could download fakeroot:
> http://www.interlude.org.uk/unix/slackware
>
> Build the package from the source I provide and in your script, do:
>
> ./configure
> blah
> make blah
>
> fakeroot
> chown -R root:bin blah
> makepkg blah

Many thanks for the info! I have just tried fakeroot (which I did not know
before).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Pawel Kot dared to utter,
>> tar retains
>> ownership and permissions of files. if you were to create a package as
>> user and then install it as root system-wide, the files *and* the
>> directories in the package would obtain ownership and permissions of the
>> user that created the package.
>
> That's why (among other reasons) the post-install script idea was invented.

It's poor form (IMO) to rely on a post-install script to handle
permissions cleanly. There's a lot of variables that could go wrong,
specifically setting permissions that are insecure or non-functional.
For example, let's suppose for a moment you compiled an apache package
with suexec and did so as a user. In order to know exactly what you
need to set your permissions to, you really need to run "make install"
to be sure you got things correct, and at that point, why are you
bothering to do it twice? In short, a lot of complication that can
break things, and a lot of wasted time and energy.

Like I said in another post. If you can't trust the source code you're
compiling to behave during the compile, why are you compiling it in the
first place?

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB9aCylKR45I6cfKARAstCAJ48REZS0PsFNGAscU/3/bgca9AlUQCeLGBJ
/p4aomB5S6a3nmmBOM+h8Ik=
=nfei
-----END PGP SIGNATURE-----

Olive wrote:
> You mistake the fact that the kernel does not allow to change the ownership
> of a file (which is expected) and the possibility for a normal user to
> create a tar archive where the files has whatever owner recorded.

i do not mistake any such thing. i'm well aware of the difference, i just
wasn't aware that tar gives you that option.

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

+Alan Hicks+ wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In alt.os.linux.slackware, Pawel Kot dared to utter,
>>> tar retains
>>> ownership and permissions of files. if you were to create a package as
>>> user and then install it as root system-wide, the files *and* the
>>> directories in the package would obtain ownership and permissions of the
>>> user that created the package.
>>
>> That's why (among other reasons) the post-install script idea was
>> invented.
>
> It's poor form (IMO) to rely on a post-install script to handle
> permissions cleanly. There's a lot of variables that could go wrong,
> specifically setting permissions that are insecure or non-functional.

That's the job for the packager. Ensure that package is done correctly.
There's not much difference in ensuring the permissions are correct when
preparing the package and when installing the package.

> For example, let's suppose for a moment you compiled an apache package
> with suexec and did so as a user. In order to know exactly what you
> need to set your permissions to, you really need to run "make install"
> to be sure you got things correct, and at that point, why are you
> bothering to do it twice? In short, a lot of complication that can
> break things, and a lot of wasted time and energy.

make install is easy. Upgrading from this may not be that easy. Preparing
packages as root may be dangerous (when eg. accidently overwrite some
files). Why do something as root what you don't need to?

> Like I said in another post. If you can't trust the source code you're
> compiling to behave during the compile, why are you compiling it in the
> first place?

installing <> compiling. I've seen a lot of programs that had fcked up build
scripts and vice versa.

take care,
pkot
--
p k o t a t b e z s e n s u d o t p l
http://www.gnokii.org/