On Thu, 23 Dec 1999, Ookhoi wrote:
> > I will try to reproduce it at home It seems to be quite useful for ISP
> > setups... In the meantime, did you try giving
> >
> > chroot /usr/remote /bin/bash
> >
> > as your login shell? Of course enter it into /etc/shells as well. I did
> > not
Hi Robert,
> > > > And this works:
> > > > expanse:~# chroot /usr/remote/ su - ookhoi
> > > > ookhoi $
> > > >
> > > > Of course bash is there:
> > > > ookhoi $ /bin/bash
> > > > ookhoi $
> > >
> > > And is it in the chrooted /etc/shells?
> >
> > Thanx you for your response! Yes, it is:
> >
Hi Robert,
> > > On Sun, Dec 12, 1999 at 12:04:09PM -0500, Nagilum wrote:
> > > > I had read some docs which mentioned that on SysV, you can specify a *
> > > > in
> > > > the 7th field of the passwd file (thisis from memory, I may be off) and
> > > > that user's login will then be chroot()ed to
On Thu, 23 Dec 1999, Ookhoi wrote:
> Hi Ben,
>
> > On Sun, Dec 12, 1999 at 12:04:09PM -0500, Nagilum wrote:
> > > I had read some docs which mentioned that on SysV, you can specify a * in
> > > the 7th field of the passwd file (thisis from memory, I may be off) and
> > > that user's login will
Hi Ben,
> On Sun, Dec 12, 1999 at 12:04:09PM -0500, Nagilum wrote:
> > I had read some docs which mentioned that on SysV, you can specify a * in
> > the 7th field of the passwd file (thisis from memory, I may be off) and
> > that user's login will then be chroot()ed to his home directory.
> >
> >
Jim Breton writes:
> I would if they weren't all in the same dir Plus lots of other useful
> things like chmod.
>
> OTOH, anyone who did manage to hack an account with a restricted shell
> wouldn't have any business running chmod, so I suppose you could get away
> with just taking /bin
I would if they weren't all in the same dir Plus lots of other useful
things like chmod.
OTOH, anyone who did manage to hack an account with a restricted shell
wouldn't have any business running chmod, so I suppose you could get away
with just taking /bin out of his path. But then I imagine
Jim Breton wrote:
>
> Restricted shell is ok but too easy to get out of, just run a different
> shell and bam, you're "free." ;P
But with a restricted shell you can't run anything that isn't in your
path, so just take all shells out of the path and bam, you're restricted
again! :)
HTH,
Stuart.
On Sun, 12 Dec 1999, Ben Collins wrote:
>
> 2) The shell must be available in the chrooted env (as well as all needed
> bianries).
>
> So for this to work, you must have a complete working filesystem in each
> home directory (/home/foo/dev /home/foo/bin /home/foo/usr/bin /home/foo/etc
> ...).
>
On Sun, 12 Dec 1999, William T Wilson wrote:
> Giving a user a chrooted home won't be an easy task. You need to have a
> fully functional system under there - that means the shell, libc, and all
> that jazz. Are you sure you can't do what you want to do with a
> restricted shell?
I primarily wa
On Sun, 12 Dec 1999, Nagilum wrote:
> So, I tried changing a user's login shell to '*/bin/bash' to no avail.
> When I attempt to login, I am asked for the username.. and then I am
> asked for the password twice and booted out.
Giving a user a chrooted home won't be an easy task. You need to have
On Sun, Dec 12, 1999 at 12:04:09PM -0500, Nagilum wrote:
> I had read some docs which mentioned that on SysV, you can specify a * in
> the 7th field of the passwd file (thisis from memory, I may be off) and
> that user's login will then be chroot()ed to his home directory.
>
> I was hoping to find
I had read some docs which mentioned that on SysV, you can specify a * in
the 7th field of the passwd file (thisis from memory, I may be off) and
that user's login will then be chroot()ed to his home directory.
I was hoping to find a similar functionality in Debian, so I tried the *
in the 7th fie
13 matches
Mail list logo
