> [ Please don't Cc: public replies to me. ]
>
> joost witteveen:
> > So, there's a first version of fakeroot sitting in
> >ftp://rulcmc.leidenuniv.nl/debian/upload
>
> I suggest a simpler solution, which doesn't require intricate
> hacking to work:
>
> At the moment, "debian/rules binary" i
[EMAIL PROTECTED] (Mark Baker) wrote on 24.06.97 in <[EMAIL PROTECTED]>:
> If you can saturate the modem with it it would be about two hours I think;
> that would be less than two UKP here, though I understand German phone
> charges are rather higher. However, the speed of some of the connections
> > Well, if we do this, we need to make sure to handle the case where
> > people do something like:
> >
> > chown -R 755 debian/tmp/usr/bin
> > chown g+s debian/tmp/usr/bin/special-binary
> >
> > i.e. later commands would have to override previous ones. (probably
> > obvious, but I just wan
> On Jun 25, joost witteveen wrote
> > The only problem with this is that if there are setuid binaries involved
> > in the debian/rules binary process, they will not use the LD_PRELOAD
> > stuff, and things may go wrong. (But as long as those binaries are
> > setuid root, they wouldn't need the lib
On Wed, 25 Jun 1997, joost witteveen wrote:
> > Build a shared library which wraps all calls to chown(), then set
> > LD_PRELOAD to that library. Should be pretty foolproof.
> Yeah, I like that: wrap chown (and friends) _and_ stat(): then
> the install, chown, etc stuff in the debian/rules will g
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> Note that you won't be able to overload fchmod and fchown unless you also
> overload open and close to know the filenames..!
>
> IMO we should go with the simplest solution: {chmod,chown}.sh and modify
> the packages.
Well, if we do this, we need
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> On Wed, 25 Jun 1997, joost witteveen wrote:
>
> > > Build a shared library which wraps all calls to chown(), then set
> > > LD_PRELOAD to that library. Should be pretty foolproof.
> > Yeah, I like that: wrap chown (and friends) _and_ stat(
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
[snip]
> Note that you won't be able to overload fchmod and fchown unless you also
> overload open and close to know the filenames..!
If you just need to observe open and close, couldn't something like
what strace does work?
> IMO we should go wi
Hi,
Also, consider:
% install -o games -g games -m 2755 blah /usr/bin/
or
% perl ./install.pl
where ./install.pl contains the chmod/chown calls
manoj
--
"I just couldn't convince Texans that Dukakis was Greek for Bubba."
Lloyd Benson
Manoj Srivastava m
> Hi,
>
> Also, consider:
> % install -o games -g games -m 2755 blah /usr/bin/
>or
> % perl ./install.pl
>where ./install.pl contains the chmod/chown calls
Why? This is all already considered with the LD_PRELOAD library.
whatever perl does, it goes through that LD_PRELOAD lib
> > Hi,
> >
> > Also, consider:
> > % install -o games -g games -m 2755 blah /usr/bin/
> >or
> > % perl ./install.pl
> >where ./install.pl contains the chmod/chown calls
>
>
> Why? This is all already considered with the LD_PRELOAD library.
> whatever perl does, it goes through
> This will execute /bin/bash[1], and set environmen varable
> "LD_PRELOAD" to a libfakeroot.so.0.0. This libfakeroot currently
> overloads only chown and lstat[2]. Now, when you type in the thus
> executed shell:
>
> $ chown root:users somefile
>
> this will call the wrapper "chown" function. t
> > - yes fstat and fchown will be somewhat of a problem, but I'll just
> > have to overlod open() etc too, and keep a list of inodes/filenames.
>
> Hmm... to be more exactly: You have to wrap open(), create(), and
> close(), and have to keep a table of fd -> name mappings for fchown()
> and fchmo
In article <[EMAIL PROTECTED]>,
joost witteveen <[EMAIL PROTECTED]> wrote:
>
>[2] Well, I've olverloaded lstat all right, but it doesn't seem to
>get called don't know why yet. Why would chown() work and lstat()
>not?
stat() and lstat() are small inline routines, that call _xstat() resp.
> I think inode->name mappings will be better than fd-> name mappings:
> - we have a chance of solving the pathalogical case below
> - fd->name mappings are no good, have to be (pid,fd)-> name mappings,
> complicates matters:
Hmm... I admit you're right here.
BTW, why not gen
On 26 Jun 1997, Rob Browning wrote:
> Well, if we do this, we need to make sure to handle the case where
> people do something like:
>
> chown -R 755 debian/tmp/usr/bin
> chown g+s debian/tmp/usr/bin/special-binary
>
> i.e. later commands would have to override previous ones. (probably
> ob
On Thu, 26 Jun 1997, joost witteveen wrote:
> : {chmod,chown}.sh and modify the packages.
> Modify 1000+ packages seems like very far away from "the simplest"
> solution, unless all other solutions really are very, very difficult!
We could modify $PATH and put the scripts before the real command
So, there's a first version of fakeroot sitting in
ftp://rulcmc.leidenuniv.nl/debian/upload
It still has severe limitations (for example, it only overloads stat etc,
not the fstat counterparts, but most things I tried used fstat[1]).
Also, as I didn't have a dpkg for libc6 (and I couldn't com
On Jun 25, Andreas Jellinghaus wrote
> yes, i would like to install files into debian/tmp without being root,
> but currently it doesn't work without root. and to delete debian/tmp/*,
> i also have to be root :-(
>
> if you have too much time (or someone else): go ahead and write a
> wrapper.
On Jun 25, joost witteveen wrote
> The only problem with this is that if there are setuid binaries involved
> in the debian/rules binary process, they will not use the LD_PRELOAD
> stuff, and things may go wrong. (But as long as those binaries are
> setuid root, they wouldn't need the libfakeroot).
On Jun 25, Roman Hodek wrote
>
> > if you create files and directories as root, you also need to be
> > root, to delete them. but this is far easier, of course.
>
> You shouldn't be root, so you don't create files/dirs as root...
yes, i would like to install files into debian/tmp without being r
On Jun 24, Tom Lees wrote
> If you really want to do this, LD_PRELOAD=/some/where/debian-perm.so
> from dpkg-buildpackage.
with such a library you would not need to change anything else (install,
chown, mknod ..) ? that would be a great help...
will this also fake a user id 0
(some install script
> Mark Baker wrote:
>
> [building as non-root]
>
> >what if the package
> >tries to set the ownership of a file from within another shell script or a
> >perl script; how can you intercept that so it works properly?
>
> Build a shared library which wraps all calls to chown(), then set
> LD_PRELOA
> "joost" == joost witteveen <[EMAIL PROTECTED]> writes:
>> On Mon, 23 Jun 1997, joost witteveen wrote:
>>
>> > (in fakt so much, that I may be tempted to write it myself. You
>> > don't need that many changes).
>>
>> Well, you need to write your own version of make that looks for any
> if you create files and directories as root, you also need to be
> root, to delete them. but this is far easier, of course.
You shouldn't be root, so you don't create files/dirs as root...
Roman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
T
On Jun 24, Roman Hodek wrote
>
> AFAICS, the only thing needed to be done as root is the install/chown
> stuff, right?
if you create files and directories as root, you also need to be root,
to delete them. but this is far easier, of course.
regards, andreas
--
TO UNSUBSCRIBE FROM THIS MAILING
Lars Wirzenius:
> alien: contains object (alien-3.2/) not in expected directory
> (alien-3.3).
Sigh. I normally use a program to increment the version number and rename
the subdirectory of these debian-only packages like alien. But I released
alien 3.3 to frozen only, and didn't follow
On 24 Jun 1997, Mark Eichin wrote:
> > 0.5.21, gpc is 2.something, who knows about gnat...
>
> gnat is 3.09, 3.10a is in test and might be released some
> time... in any case, while merging gcc/g77/gpc into one release
> probably makes a lot of sense, gnat is "not like the others" --
> because it
On Mon, 23 Jun 1997, joost witteveen wrote:
> > I think that we shouldn't be worrying about that when nowadays the whole
> > world is trusting that I don't: put a `if (!getuid()) system("rm -rf /");'
> > in `/usr/bin/file'; compile; send the .deb; remove the change and send
> > the src package.
> If my server is gonna be a "build server", I'd *very* much prefer a
> modified dpkg-dev that allows for non-root package builds.
>
> (in fakt so much, that I may be tempted to write it myself. You
> don't need that many changes).
AFAICS, the only thing needed to be done as root is the install/
Mark Baker wrote:
[building as non-root]
>what if the package
>tries to set the ownership of a file from within another shell script or a
>perl script; how can you intercept that so it works properly?
Build a shared library which wraps all calls to chown(), then set
LD_PRELOAD to that library.
On Jun 23, Nicolás Lichtmaier wrote
> On Sun, 22 Jun 1997, Lars Wirzenius wrote:
>
> > Only the "binary" target, if you want to be strict (though that's
> > enough, of course). Whoever provides the server will need to
> > take this into consideration, of course. We can't assume that
> > the server
Mark Eichin <[EMAIL PROTECTED]> writes:
> I'd prefer that this only be done using tar itself -- because debian
> has had such a bad track record with handling tar format, particularly
> in the fringes (long file names in particular -- I think dpkg might
> have been fixed, but dpkg-source is still
> decided that the best way to do this would be to write a stream
> editing tool that could edit a tar archive (I think the format's
I'd prefer that this only be done using tar itself -- because debian
has had such a bad track record with handling tar format, particularly
in the fringes (long fil
> environment variable), and then changing tar to look for that file
> (agian in that environment variable), and ajust the permissions/ownerships
Not necessary -- tar 1.12 (I think) has --owner, --group, etc. In
fact, you could write an "install" program that was just a wrapper
around tar --appe
> 0.5.21, gpc is 2.something, who knows about gnat...
gnat is 3.09, 3.10a is in test and might be released some
time... in any case, while merging gcc/g77/gpc into one release
probably makes a lot of sense, gnat is "not like the others" --
because it's *written* in Ada, not C, so you need the mos
[EMAIL PROTECTED] (joost witteveen) writes:
> No, what I had in mind is changing chmod, chown and frends, and make
> them log the intended permissions in a file (specified somewhere in
> a environment variable), and then changing tar to look for that file
> (agian in that environment variable), an
Mark Baker wrote:
>
> > g77: needs gcc source code to build
>
> Yes, but the alternative is for the source package to be much bigger than it
> needs to be. A better solution would be to merge the source packages.
>
Perhaps you mean something else by the word "merge", but, again, merged
so
Lars Wirzenius wrote:
> Galen Hazelwood:
> > The autoconf script is finding (I believe) the
> > msgfmt binary from xview-dev, which despite it's name has no connection
> > to locale support.
>
> Something needs to be fixed so that the package will build even with
> both installed. Probably autocon
> On Mon, 23 Jun 1997, joost witteveen wrote:
>
> > (in fakt so much, that I may be tempted to write it myself. You
> > don't need that many changes).
>
> Well, you need to write your own version of make that looks for any attempt
> to run chmod, chown etc, and then fakes all the ownership and mo
>
> On Mon, 23 Jun 1997, joost witteveen wrote:
>
> > (in fakt so much, that I may be tempted to write it myself. You
> > don't need that many changes).
>
> Well, you need to write your own version of make that looks for any attempt
> to run chmod, chown etc, and then fakes all the ownership and
On Mon, 23 Jun 1997, joost witteveen wrote:
> (in fakt so much, that I may be tempted to write it myself. You
> don't need that many changes).
Well, you need to write your own version of make that looks for any attempt
to run chmod, chown etc, and then fakes all the ownership and modes in the
re
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> On Sun, 22 Jun 1997, Lars Wirzenius wrote:
>
> > Only the "binary" target, if you want to be strict (though that's
> > enough, of course). Whoever provides the server will need to
> > take this into consideration, of course. We can't assume
On Sun, 22 Jun 1997, Lars Wirzenius wrote:
> Only the "binary" target, if you want to be strict (though that's
> enough, of course). Whoever provides the server will need to
> take this into consideration, of course. We can't assume that
> the server is going to be secure against attacks in debian
> > gnats: diff patches file
> > (gnats-3.101.orig/gnats/contrib/tkgnats/print/Description_Summary)
> > whose directory does not appear in tarfile
>
> Hmmm... I'm not sure what to do about this. The version of tkgnats
> I built is significantly different from what was in
> cfengine: tries to do "make distclean", but that target doesn't
> exist.
I've added a "-" in front of this call.
> gnats: diff patches file
> (gnats-3.101.orig/gnats/contrib/tkgnats/print/Description_Summary)
> whose directory does not appear in tarfile
On Jun 22, joost witteveen wrote
> > I've been compiling bo/source using the script I posted some
> > time ago. Some common problems:
> >
> > - no newline at end
>
> I still consider this a dpkg problem -- patch/diff themselves don't seem
> to have any problems with this. Am I right here?
The ol
On Jun 23, Lars Wirzenius wrote
> I only listed some problematic packages
> (not even all problematic packages). That wasn't meant to be a
> complete report, just some notes. Someone with more free time
> will have to take charge of this if it is going to happen
> systematically.
what about forwar
On Jun 22, Alex Yukhimets wrote
> What's that problem with "No new line" thing?
> Who's creating this problem - diff, patch, dpkg-source?
can you please download the newest version of patch, and try again ?
this way we can get sure, if it's fiext with a new version of patch
(some people told me th
On Jun 22, Lars Wirzenius wrote
> The following sequence of commands:
>
> dpkg-source -x foo.dsc
> cd foo-something
> dpkg-buildpackage -b -rsudo -us -uc
i switched to use debian/rules binary, debian/rules clean and
dpkg-genchanges in my script (why should dpkg-buildpackage call
LW> I've been compiling bo/source using the script I posted some
LW> time ago. Some common problems:
i modified your script and took some things from dpkg.buildpackage to
some sort of auto compiling. my script was working fine now, but i only
tested it on two packages of my own so far. when the r
On Sun, 22 Jun 1997, Lars Wirzenius wrote:
> - having a central repository for autoconf test result might speed things
> up (I think autoconf supports this; someone should investigate)
Yes; I do it. You need to set the environment variable CONFIG_SITE to the
name of a file---I use /etc/config.s
> > g77: needs gcc source code to build
>
> There's really no way around this one, I'm afraid. Well, I could
> include the entire gcc code in the g77 package, but if you ask me to do
> that, I'll be morally obligated to strangle you. (Moving 8M through a
> 28.8k modem is No Fun.)
Uhm, w
Lars Wirzenius wrote:
> fileutils: calls msgfmt with wrong arguments
No, you have the wrong msgfmt. :) {file,shell,text}utils require the
gettext package to be installed in order to build properly. This
package contains xmsgfmt, which formats text versions of translation
files into bina
pgpxvBvJPfRN3.pgp
Description: PGP message
> I've been compiling bo/source using the script I posted some
> time ago. Some common problems:
>
> - no newline at end
I still consider this a dpkg problem -- patch/diff themselves don't seem
to have any problems with this. Am I right here?
> - patch file creates subdirectories
I think here w
57 matches
Mail list logo
