[ale] Doing a chroot in Perl

Jerry Yu jjj863 at gmail.com
Wed Aug 30 11:17:40 EDT 2006


pardon me, the first 'id -a' should have been:
$ id -a
uid=500 gid=500 groups=0,1,2,3,4,6,10 context=root:system_r:unconfined_t


On 8/30/06, Jerry Yu <jjj863 at gmail.com> wrote:
>
> The supplemetary GIDs are still there, after the setgid/setuid calls. This
> makes the jailed 'tomcat' has read/write access granted to group 0 1 2 3 4 6
> 10. For instance, now tomcat can read "/proc/net/ip_conntrack" which tomcat
> outside the jail wouldn't be able to read.
>
> before setsid/gid  $) = (0 10 6 4 3 2 1 0)
> after setsid/gid   $) = (500 10 6 4 3 2 1 0)
> $ id -a
>
> uid=500 gid=500 groups=500 context=root:system_r:unconfine
> d_t
>
> Per 'perldoc perlvar', you'd need to set $)="$gid $gid" to rid of the
> extra supplemetary GIDs from the original owner.
> $) = (0 10 6 4 3 2 1 0)
> $) = (500 500)
> $ id -a
> uid=500 gid=500 groups=500 context=root:system_r:unconfined_t
>
>
> On 8/30/06, Christopher Fowler <cfowler at outpostsentinel.com> wrote:
>
> > I figured it out.
> >
> > ScriptExecRoot is owned by root but a subdirectory of SAM which is owned
> > by tomcat. When I did the chroot even though / was owned by root I as
> > tomcat was able to write stuff anywhere I wanted.
> >
> > I moved ScriptExecRoot to /opt which is owned by root.  Now when I
> > chroot I was not able to write anywhere I wanted.
> >
> > I guess this is normal behavior but I did not expect it.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...




More information about the Ale mailing list