On centos 4 (i386 chroot on an x86_64) it just prompts me for a password.
Any suggesstion on where to start looking?
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jason Pyeron Sent: Sunday, August 01, 2010 10:34 To: 'CentOS mailing list' Subject: [CentOS] /bin/su wont work inside a chroot?
On centos 4 (i386 chroot on an x86_64) it just prompts me for a password.
Any suggesstion on where to start looking?
So my hack will not work either...
[root@devserver21 ~]# echo 0 >/selinux/enforce [root@devserver21 ~]# chroot /var/mnt/192.168.1.52 [root@devserver21 /]# passwd apache passwd: user_u:system_r:initrc_t is not authorized to change the password of apache [root@devserver21 /]#
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jason Pyeron Sent: Sunday, August 01, 2010 11:01 To: 'CentOS mailing list' Subject: Re: [CentOS] /bin/su wont work inside a chroot?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jason Pyeron Sent: Sunday, August 01, 2010 10:34 To: 'CentOS mailing list' Subject: [CentOS] /bin/su wont work inside a chroot?
On centos 4 (i386 chroot on an x86_64) it just prompts me for a password.
Any suggesstion on where to start looking?
So my hack will not work either...
[root@devserver21 ~]# echo 0 >/selinux/enforce [root@devserver21 ~]# chroot /var/mnt/192.168.1.52 [root@devserver21 /]# passwd apache passwd: user_u:system_r:initrc_t is not authorized to change the password of apache [root@devserver21 /]#
I think my solution is to use http://ftp.gnu.org/gnu/coreutils/coreutils-8.5.tar.gz and create a ~/bin/newchroot
I think I am on my way, but why can I not su in a chroot???
[root@devserver21 coreutils-8.5]# ./src/chroot --help Usage: ./src/chroot [OPTION] NEWROOT [COMMAND [ARG]...] or: ./src/chroot OPTION Run COMMAND with root directory set to NEWROOT.
--userspec=USER:GROUP specify user and group (ID or name) to use --groups=G_LIST specify supplementary groups as g1,g2,..,gN --help display this help and exit --version output version information and exit
If no command is given, run ``${SHELL} -i'' (default: /bin/sh).
Report chroot bugs to bug-coreutils@gnu.org GNU coreutils home page: http://www.gnu.org/software/coreutils/ General help using GNU software: http://www.gnu.org/gethelp/ For complete documentation, run: info coreutils 'chroot invocation' [root@devserver21 coreutils-8.5]# exit [root@devserver21 ~]# cp /var/mnt/192.168.1.52/tmp/coreutils-8.5/./src/chroot ~/bin/newchroot [root@devserver21 ~]# newchroot --userspec=apache:apache /var/mnt/192.168.1.52 [apache@devserver21 /]$ cd /usr/src/redhat/ [apache@devserver21 redhat]$ rpmbuild -ba SPECS/subversion.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.63999
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
On 08/01/2010 08:01 AM, Jason Pyeron wrote:
So my hack will not work either... [root@devserver21 ~]# echo 0>/selinux/enforce [root@devserver21 ~]# chroot /var/mnt/192.168.1.52 [root@devserver21 /]# passwd apache passwd: user_u:system_r:initrc_t is not authorized to change the password of apache
How'd you end up in that context? Did you boot to single-user mode?
I only have CentOS 5 on which to test. On the host, root normally logs in to an unconfined domain:
# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
If I chroot, I'm still unconfined:
# chroot /var/lib/mock/centos-5-x86_64/root/ bash-3.2# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t:s0
... and why you'd be getting SELinux warnings after disabling enforcing mode is odd, too. What to "getenforce" and "setenforce permissive" tell you? Is /selinux actually a mounted filesystem?
Jason Pyeron <jpyeron@...> writes:
On centos 4 (i386 chroot on an x86_64) it just prompts me for a password.
Any suggesstion on where to start looking?
--
-- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
Just as a guess, you need to have an appropriate sudoers file in the correct location relative to the chrooted root. Pulling some information from one of your follow up posts, that would be:
/var/mnt/192.168.1.52/etc/sudoers
Once you chroot, programs look for files in their normal locations but relative to whatever the new root is.
Cheers, Dave
On Sun, 2010-08-01 at 16:20 +0000, Dave Miller wrote:
Jason Pyeron <jpyeron@...> writes:
On centos 4 (i386 chroot on an x86_64) it just prompts me for a password.
Any suggesstion on where to start looking?
--
-- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
Just as a guess, you need to have an appropriate sudoers file in the correct location relative to the chrooted root. Pulling some information from one of your follow up posts, that would be:
/var/mnt/192.168.1.52/etc/sudoers
Once you chroot, programs look for files in their normal locations but relative to whatever the new root is.
Cheers, Dave
--- Or be dirty and symlink it out to the main root /etc/sudoers...of which may create your security problem in present.....tense
John
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of JohnS Sent: Sunday, August 01, 2010 12:30 To: CentOS mailing list Subject: Re: [CentOS] /bin/su wont work inside a chroot?
On Sun, 2010-08-01 at 16:20 +0000, Dave Miller wrote:
Jason Pyeron <jpyeron@...> writes:
On centos 4 (i386 chroot on an x86_64) it just prompts me
for a password.
Any suggesstion on where to start looking?
--
-- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
Just as a guess, you need to have an appropriate sudoers
file in the
Curious, I am trying to use su not sudo...
correct location relative to the chrooted root. Pulling some information from one of your follow up posts, that would be:
/var/mnt/192.168.1.52/etc/sudoers
Once you chroot, programs look for files in their normal
locations but
relative to whatever the new root is.
Cheers, Dave
Or be dirty and symlink it out to the main root /etc/sudoers...of which may create your security problem in present.....tense
[root@devserver21 etc]# cat sudoers # sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # See the sudoers man page for the details on how to write a sudoers file. #
# Host alias specification
# User alias specification
# Cmnd alias specification
# Defaults specification
# User privilege specification root ALL=(ALL) ALL
# Uncomment to allow people in group wheel to run all commands # %wheel ALL=(ALL) ALL
# Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL
# Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now
[root@devserver21 etc]# sudo su -l apache failed to get default context [root@devserver21 etc]# sudo su apache failed to get default context [root@devserver21 etc]# sudo [root@devserver21 etc]#
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
On Sun, 2010-08-01 at 13:22 -0400, Jason Pyeron wrote:
[root@devserver21 etc]# sudo su -l apache failed to get default context [root@devserver21 etc]# sudo su apache failed to get default context [root@devserver21 etc]# sudo [root@devserver21 etc]#
----- Well how are you creating the chroot? and why do you want to build an rpm as apache? and is this over nfs? If so it will not work as you would think.
Try creating the chroot in /tmpfs?
Heres what I get [root@ethies ~]# sudo su -l apache This account is currently not available.
[root@ethies ~]# su apache This account is currently not available.
Looks like it is meant or not in sudoers....to be like this or it is a bug. SELinux is Active also. Maybe someone else can confirm this? I do not think some service accounts allow this but I know postgres does.
[root@ethies ~]# su postgres bash-3.2$
John
Am 01.08.2010 20:55, schrieb JohnS:
On Sun, 2010-08-01 at 13:22 -0400, Jason Pyeron wrote:
[root@devserver21 etc]# sudo su -l apache failed to get default context [root@devserver21 etc]# sudo su apache failed to get default context [root@devserver21 etc]# sudo [root@devserver21 etc]#
Well how are you creating the chroot? and why do you want to build an rpm as apache? and is this over nfs? If so it will not work as you would think.
Try creating the chroot in /tmpfs?
Heres what I get [root@ethies ~]# sudo su -l apache This account is currently not available.
[root@ethies ~]# su apache This account is currently not available.
apache has no login shell.
getent passwd apache
Looks like it is meant or not in sudoers....to be like this or it is a bug. SELinux is Active also. Maybe someone else can confirm this? I do not think some service accounts allow this but I know postgres does.
[root@ethies ~]# su postgres bash-3.2$
postgres has a login shell.
getent passwd postgres
John
Alexander
On Sun, 2010-08-01 at 20:58 +0200, Alexander Dalloz wrote:
Am 01.08.2010 20:55, schrieb JohnS:
Heres what I get [root@ethies ~]# sudo su -l apache This account is currently not available.
[root@ethies ~]# su apache This account is currently not available.
apache has no login shell.
Right :-)
getent passwd apache
Looks like it is meant or not in sudoers....to be like this or it is a bug. SELinux is Active also. Maybe someone else can confirm this? I do not think some service accounts allow this but I know postgres does.
[root@ethies ~]# su postgres bash-3.2$
postgres has a login shell.
getent passwd postgres
John
Alexander
--- Alex would be right! I went to the kitchen and thought about it and come up with the same thing No /bin/bash. :-)
Jason Pyeron wrote:
[root@devserver21 etc]# sudo su -l apache failed to get default context [root@devserver21 etc]# sudo su apache failed to get default context [root@devserver21 etc]# sudo [root@devserver21 etc]#
References to 'context' would have something to do with SELinux, not normal permissions.
On Sun, 2010-08-01 at 14:10 -0500, Les Mikesell wrote:
Jason Pyeron wrote:
[root@devserver21 etc]# sudo su -l apache failed to get default context [root@devserver21 etc]# sudo su apache failed to get default context [root@devserver21 etc]# sudo [root@devserver21 etc]#
References to 'context' would have something to do with SELinux, not normal permissions.
--- That's is also because his echoed "0" context is not active yet. It requires a reboot every time I have done it. But the other way around it does not.
No matter how hard you try in a default EL4 or 5 instance you will never get logged into an apache account. Root or Not... Unless you change the login shell..or exploit it...
apache = /sbin/nologin postgres = /sbin/bash ################################################# Jason,
Nasty things happen when you build rpms like that. See www.owlriver.com , Russ has an article there about it [1].
[1] http://www.owlriver.com/tips/non-root/
John
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of JohnS Sent: Sunday, August 01, 2010 15:28 To: CentOS mailing list Subject: Re: [CentOS] /bin/su wont work inside a chroot?
On Sun, 2010-08-01 at 14:10 -0500, Les Mikesell wrote:
Jason Pyeron wrote:
[root@devserver21 etc]# sudo su -l apache failed to get default context [root@devserver21 etc]# sudo su apache failed to get
default context
[root@devserver21 etc]# sudo [root@devserver21 etc]#
References to 'context' would have something to do with
SELinux, not normal
permissions.
That's is also because his echoed "0" context is not active yet. It requires a reboot every time I have done it. But the other way around it does not.
No matter how hard you try in a default EL4 or 5 instance you will never get logged into an apache account. Root or Not... Unless you change the login shell..or exploit it...
Forgot to tell you in the chroot I did change the login shell for apache to /bin/bash
apache = /sbin/nologin postgres = /sbin/bash ################################################# Jason,
Nasty things happen when you build rpms like that. See www.owlriver.com , Russ has an article there about it [1].
Agreed. I am hacking together a solution to put in to our mockbuilder. Needed to have a working subversion 1.6.x in our yum repo by Monday morning (client deliverable). I have goten everything to work until subversions make test launches apache as root.... It just produced the 1st mod_dav_svn-1.6.12 rpm as I was typing this email.
Give me ten minutes I will publish the src.rpms...
[1] http://www.owlriver.com/tips/non-root/
John
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
On Sun, 2010-08-01 at 16:00 -0400, Jason Pyeron wrote:
Nasty things happen when you build rpms like that. See www.owlriver.com , Russ has an article there about it [1].
Agreed. I am hacking together a solution to put in to our mockbuilder. Needed to have a working subversion 1.6.x in our yum repo by Monday morning (client deliverable). I have goten everything to work until subversions make test launches apache as root.... It just produced the 1st mod_dav_svn-1.6.12 rpm as I was typing this email.
Give me ten minutes I will publish the src.rpms...
--- I would be very skeptical as launching apache as root. Would like to see that specfile though, you can su in the specfile it self to switch to another user or daemon. I have an rpm that does just that.
John
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of JohnS Sent: Sunday, August 01, 2010 16:18 To: CentOS mailing list Subject: Re: [CentOS] /bin/su wont work inside a chroot?
On Sun, 2010-08-01 at 16:00 -0400, Jason Pyeron wrote:
Nasty things happen when you build rpms like that. See www.owlriver.com , Russ has an article there about it [1].
Agreed. I am hacking together a solution to put in to our
mockbuilder.
Needed to have a working subversion 1.6.x in our yum repo by Monday morning (client deliverable). I have goten everything to work until subversions make test launches apache as root.... It just
produced the
1st mod_dav_svn-1.6.12 rpm as I was typing this email.
Give me ten minutes I will publish the src.rpms...
I would be very skeptical as launching apache as root. Would
I did not and could not lauch apache as root, that is why I recompiled the chroot so I could use my build env as a non-root user.
like to see that specfile though, you can su in the specfile it self to switch to another user or daemon. I have an rpm that does just that.
Specfiles herein:
http://client.pdinc.us/subversion-1.6.12-yumrepo/
Please rip them apart.
Known issues:
1. python2.3 does not provide /usr/bin/python (breaks yum until you fix the #! line) 2. subversion has issues with swig at the moment and no attempt to make the perl or python parts. 3. subversion makes no attempt to use bdb. 4. the binary subversion-tools rpm depends on the unbilt subversion-perl rpm. 5. subversion build test are slow!
-Jason
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
On Sun, 2010-08-01 at 16:46 -0400, Jason Pyeron wrote:
I would be very skeptical as launching apache as root. Would
I did not and could not lauch apache as root, that is why I recompiled the chroot so I could use my build env as a non-root user.
like to see that specfile though, you can su in the specfile it self to switch to another user or daemon. I have an rpm that does just that.
Specfiles herein:
http://client.pdinc.us/subversion-1.6.12-yumrepo/
Please rip them apart.
Known issues:
- python2.3 does not provide /usr/bin/python (breaks yum until you fix the #!
line) 2. subversion has issues with swig at the moment and no attempt to make the perl or python parts. 3. subversion makes no attempt to use bdb. 4. the binary subversion-tools rpm depends on the unbilt subversion-perl rpm. 5. subversion build test are slow!
-Jason
Jason,
Umm what version OS are they for el5? Yum may break also. I really think they are to new of rpms. Upstreams subversion is not even that high in el6 and it does not even do a make test in the spec. Python maybe to new also. Will they fully dependency solve?
John
Check this out: ftp://ftp.redhat.com/redhat/rhel/beta/6Server-beta2/source/SRPMS/subversion-1.6.11-1.el6.src.rpm
On Sun, 2010-08-01 at 16:46 -0400, Jason Pyeron wrote:
Specfiles herein:
http://client.pdinc.us/subversion-1.6.12-yumrepo/
Please rip them apart.
Known issues: --- Looked at subversion: Love the specfile: %changelog in the middle of the spec. Atleast you % clean... Disregard the earlier comment about the test in the spec, I see where it comes in at now. Well I hope they work. There is no define %{?dist}.
John
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of JohnS Sent: Sunday, August 01, 2010 18:02 To: CentOS mailing list Subject: Re: [CentOS] /bin/su wont work inside a chroot?
On Sun, 2010-08-01 at 16:46 -0400, Jason Pyeron wrote:
Specfiles herein:
http://client.pdinc.us/subversion-1.6.12-yumrepo/
Please rip them apart.
Known issues:
Looked at subversion: Love the specfile: %changelog in the middle of the spec.
Time was of the essence, I took an existing subversion specfile (http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/lates... .6.6/rhel4/src/subversion-1.6.6-1.src.rpm from http://subversion.apache.org/packages.html#redhat)
Atleast you % clean... Disregard the earlier comment about the test in the spec, I see where it comes in at now. Well I hope they work. There is no define %{?dist}.
Aside from the known issues, it works like a charm.
John
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
On Sun, 2010-08-01 at 21:02 -0400, Jason Pyeron wrote:
Known issues:
Looked at subversion: Love the specfile: %changelog in the middle of the spec.
Time was of the essence, I took an existing subversion specfile (http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/lates... .6.6/rhel4/src/subversion-1.6.6-1.src.rpm from http://subversion.apache.org/packages.html#redhat)
Atleast you % clean... Disregard the earlier comment about the test in the spec, I see where it comes in at now. Well I hope they work. There is no define %{?dist}.
Aside from the known issues, it works like a charm.
--- Great
John
On 08/01/2010 12:28 PM, JohnS wrote:
That's is also because his echoed "0" context is not active yet. It requires a reboot every time I have done it.
No, rebooting will reset any changes made to files in /selinux.
No matter how hard you try in a default EL4 or 5 instance you will never get logged into an apache account. Root or Not... Unless you change the login shell..or exploit it...
It's not hard, you just have to specify a shell to use:
# su - apache -s /bin/bash
On Sun, 2010-08-01 at 17:35 -0700, Gordon Messmer wrote:
On 08/01/2010 12:28 PM, JohnS wrote:
That's is also because his echoed "0" context is not active yet. It requires a reboot every time I have done it.
No, rebooting will reset any changes made to files in /selinux.
What I meant was totally shutting it down. The service then reboot. Factually a machine under high load I have seen parts of /proc not get read. That I can show if you want to see it.
No matter how hard you try in a default EL4 or 5 instance you will never get logged into an apache account. Root or Not... Unless you change the login shell..or exploit it...
It's not hard, you just have to specify a shell to use:
# su - apache -s /bin/bash
That is if the shell is specified. By default it is not and that was what was brought up.
At Sun, 01 Aug 2010 12:29:47 -0400 CentOS mailing list centos@centos.org wrote:
On Sun, 2010-08-01 at 16:20 +0000, Dave Miller wrote:
Jason Pyeron <jpyeron@...> writes:
On centos 4 (i386 chroot on an x86_64) it just prompts me for a password.
Any suggesstion on where to start looking?
--
-- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
Just as a guess, you need to have an appropriate sudoers file in the correct location relative to the chrooted root. Pulling some information from one of your follow up posts, that would be:
/var/mnt/192.168.1.52/etc/sudoers
Once you chroot, programs look for files in their normal locations but relative to whatever the new root is.
Cheers, Dave
Or be dirty and symlink it out to the main root /etc/sudoers...of which may create your security problem in present.....tense
Symlink won't work. A hard link will work, but that only works if the chroot and the main root are on the same physical file system.
John
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, 2010-08-01 at 16:26 -0400, Robert Heller wrote:
Or be dirty and symlink it out to the main root /etc/sudoers...of which may create your security problem in present.....tense
Symlink won't work. A hard link will work, but that only works if the chroot and the main root are on the same physical file system.
--- It *WILL* work It is called "Outside to In" && mount -o bind will also. The difference depends on what is exactly the person needs. IE (which way). It will also allow a "Jail Break" Out & In. So security goes out the window. In effect Zero Day here we are.
I'll post up full details next time.
John
On 08/01/2010 01:44 PM, JohnS wrote:
It *WILL* work It is called "Outside to In"&& mount -o bind will also.
You previously described symlinking "out" to the root filesystem, which is impossible. Symlinks cannot resolve to files outside of a chroot environment. Hard links can.
It is, however, possible to create a symlink in the primary root filesystem which points to a file inside a tree used for chroot, if that is what you mean by "outside to in". In that case, your previous post was simply unclear.
The difference depends on what is exactly the person needs. IE (which way). It will also allow a "Jail Break" Out& In. So security goes out the window. In effect Zero Day here we are.
Symlinks do not allow you to break out of a chroot. In fact, chroot isn't a security mechanism. chroot will confine any non-root process, but any root process can escape a chroot simply by setting its cwd to the root directory and then calling chroot() to any directory. The process will then have a cwd outside its own root filesystem, and can access the filesystem outside of the path it was originally using as its chroot.
The term "zero day" normally describes a software exploit which was not previously known. I don't believe it applies to anything you described.
On Sun, 2010-08-01 at 17:41 -0700, Gordon Messmer wrote:
On 08/01/2010 01:44 PM, JohnS wrote:
It *WILL* work It is called "Outside to In"&& mount -o bind will also.
You previously described symlinking "out" to the root filesystem, which is impossible. Symlinks cannot resolve to files outside of a chroot environment. Hard links can.
lol
It is, however, possible to create a symlink in the primary root filesystem which points to a file inside a tree used for chroot, if that is what you mean by "outside to in". In that case, your previous post was simply unclear.
Correct yes.
The difference depends on what is exactly the person needs. IE (which way). It will also allow a "Jail Break" Out& In. So security goes out the window. In effect Zero Day here we are.
Symlinks do not allow you to break out of a chroot. In fact, chroot isn't a security mechanism. chroot will confine any non-root process, but any root process can escape a chroot simply by setting its cwd to the root directory and then calling chroot() to any directory. The process will then have a cwd outside its own root filesystem, and can access the filesystem outside of the path it was originally using as its chroot.
Most people choose to refer to chroot as a secure means of running a service which is simply not true. It is known in the past that non root services can jail break out and can break into the jailed root. The only good I have ever seen from chroot is building a OS from the ground up. It will only ever be as secure as the person configuring it.
The term "zero day" normally describes a software exploit which was not previously known. I don't believe it applies to anything you described.
True and there are new ones every day don't be fooled. What good is the bind service running in a chroot when you get cache poisoned? Your patches up to date? That may not even help.
John
-
Alexander Dalloz -
Dave Miller -
Gordon Messmer -
Jason Pyeron -
JohnS -
Les Mikesell -
Robert Heller