Papp,
I don't think you have stated what distro you are running in the problem
container. Most package managers offered by distros have a way to verify the
checksums of packages installed by the package manager. So enter the container
and do that. The modified files should stick out like a s
Papp Tamás wrote:
Dariush Pietrzak wrote:
chroot is not a security mechanism, so when you do this, and the tools
you're going to run are compromisied and hostile, then you have just
lost
control of your HN and all VE's running on it.
I think, for debugging it could be OK.
I mean, can
Dariush Pietrzak wrote:
chroot is not a security mechanism, so when you do this, and the tools
you're going to run are compromisied and hostile, then you have just lost
control of your HN and all VE's running on it.
I think, for debugging it could be OK.
tamas
> >> then you can make chroot /vz/root/100
> >> and then start strace
chroot is not a security mechanism, so when you do this, and the tools
you're going to run are compromisied and hostile, then you have just lost
control of your HN and all VE's running on it.
--
Key fingerprint = 40D0 9FFB 993
Papp Tamas wrote:
> Vasily Averin wrote:
>> btw
>> you can mount container by 'vzctl mount 100' command,
>> then you can make chroot /vz/root/100
>> and then start strace
>>
>
> Is it a big mistake to chroot only to /vz/private/100 without vzctl mount?
I'm not 100% sure, but I think the quota
Vasily Averin wrote:
btw
you can mount container by 'vzctl mount 100' command,
then you can make chroot /vz/root/100
and then start strace
Is it a big mistake to chroot only to /vz/private/100 without vzctl mount?
tamas
___
Users mailing list
User
Alexander Prinsier wrote:
Both these make me think that /bin/ls is corrupt. Can you take a
checksum of /bin/ls, and compare it with the /bin/ls of another system
running the same distro?
The corrupt one is smaller.
tamas
___
Users mailing list
Us
2008. 12. 4, csütörtök keltezéssel 12.58-kor Papp Tamás ezt írta:
> Pongracz Istvan wrote:
> > probably the correct way is:
> >
> > vzctl exec 100 'strace -ff /bin/ls'
> >
> > If the strace exists in the container, it must work.
> >
>
> Why shoud I want to run it like this?
>
> I know, it's no
Papp Tamás wrote:
> $ strace -ff /vz/100/root/bin/ls
> execve("/vz/100/root/bin/ls", ["/vz/100/root/bin/ls"], [/* 34 vars */])
> = -1 ENOENT (No such file or directory)
> $ ldd /vz/100/private/bin/ls
>not a dynamic executable
Both these make me think that /bin/ls is corrupt. Can you take
Pongracz Istvan wrote:
> 2008. 12. 4, csütörtök keltezéssel 12.01-kor Alexander Prinsier ezt
> írta:
>> Papp Tamás wrote:
>>> Dariush Pietrzak wrote:
> $ strace -ff /vz/100/root/bin/ls
>
You're trying to run a binary from inside the VE in HN's context? I't
dangerous.
A
Pongracz Istvan wrote:
probably the correct way is:
vzctl exec 100 'strace -ff /bin/ls'
If the strace exists in the container, it must work.
Why shoud I want to run it like this?
I know, it's not working in the container and I want to see it outside.
Thanks,
tamas
__
Alexander Prinsier wrote:
You probably mean "statically linked". /bin/ls usually is dynamically
I'm sorry, of course I mean statically linked.
linked. At least in any standard distro... Statically linked executables
aren't very common.
Well, you are right, I'm confused.
$ ldd /vz/100/pr
2008. 12. 4, csütörtök keltezéssel 12.01-kor Alexander Prinsier ezt
írta:
> Papp Tamás wrote:
> > Dariush Pietrzak wrote:
> >>> $ strace -ff /vz/100/root/bin/ls
> >>>
> >> You're trying to run a binary from inside the VE in HN's context? I't
> >> dangerous.
> >> And it probably doesn't work
> but you imagine that one have two ethernet devices connected to two
> subnets on the main host ( and thats my case)
> which is veth bridged with?
Why? What is the question?
- Dietmar
___
Users mailing list
Users@openvz.org
https://openvz.org/mailman
Papp Tamás wrote:
> Dariush Pietrzak wrote:
>>> $ strace -ff /vz/100/root/bin/ls
>>>
>> You're trying to run a binary from inside the VE in HN's context? I't
>> dangerous.
>> And it probably doesn't work because ls is linked to something in VE
>> that
>> doesn't exist on HN (try ldd /bin/ls
> /bin/ls is hardlinked, it should not depend on anything.
I don't know what you mean by 'hardlinked', most distributions ship
/bin/ls as dynamic binary, so it depends on, for example - libc, libpthread,
selinux, libacl, etc etc...
If there are mainstream dists shipping ls and other essential too
Dariush Pietrzak wrote:
$ strace -ff /vz/100/root/bin/ls
You're trying to run a binary from inside the VE in HN's context? I't
dangerous.
And it probably doesn't work because ls is linked to something in VE that
doesn't exist on HN (try ldd /bin/ls or ldd /vz/100/root/bin/ls) (which
would
> $ strace -ff /vz/100/root/bin/ls
You're trying to run a binary from inside the VE in HN's context? I't
dangerous.
And it probably doesn't work because ls is linked to something in VE that
doesn't exist on HN (try ldd /bin/ls or ldd /vz/100/root/bin/ls) (which
would be surprising, because ls is
hi!
$ strace -ff /vz/100/root/bin/ls
execve("/vz/100/root/bin/ls", ["/vz/100/root/bin/ls"], [/* 34 vars */])
= -1 ENOENT (No such file or directory)
dup(2) = 3
fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|
Hi,
but you imagine that one have two ethernet devices connected to two
subnets on the main host ( and thats my case)
which is veth bridged with?
Frank
Message: 1
Date: Wed, 3 Dec 2008 15:36:10 +0100
From: "Dietmar Maurer" <[EMAIL PROTECTED]>
Subject: RE: [Users] Samba server using veth
To:
M
20 matches
Mail list logo