Date: Mon, 12 Mar 2012 19:33:30 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: eam1edward@gmail.com, freebsd@edvax.de Cc: freebsd-questions@freebsd.org Subject: Re: Editor With NO Shell Access? Message-ID: <201203130033.q2D0XUwg048729@mail.r-bonomi.com> In-Reply-To: <4F5E7D1F.9030703@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From owner-freebsd-questions@freebsd.org Mon Mar 12 17:46:04 2012 > Date: Mon, 12 Mar 2012 15:47:59 -0700 > From: "Edward M." <eam1edward@gmail.com> > To: Polytropon <freebsd@edvax.de> > Cc: freebsd-questions@freebsd.org > Subject: Re: Editor With NO Shell Access? > > On 03/12/2012 03:23 PM, Polytropon wrote: > > On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: > >> On 03/12/2012 03:10 PM, Polytropon wrote: > >>> /etc/shells to work, but a passwd entry like > >>> > >>> bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe > >> > >> I think this would not let the user to login,etc > > I'm not sure... I assume logging in is handled by /usr/bin/login, > > and control is then (i. e. after successful login) transferred > > to the login shell, which is the program specified in the > > "shell" field (see "man 5 passwd") of /etc/passwd. How is > > login supposed to know if the program specified in this > > field is actually a dialog shell? > > > > From "man 1 login" I read that many shells have a built-in > > login command, but /usr/bin/login is the system's default > > binary for this purpose if the "shell" (quotes deserved if > > it is an editor as shown in my assumption) has no capability > > of performing a login. > > > > > > > Now i gotta try this out. Off to > hosed my system. If other configuration is set up right (e.g. /etc/shells), you can name *any* executable as the 'shell' field in /etc/passwd, and have it work. "Long, long, ago", I used this for client 'on demand' system back-up. They just put the tape in the drive, and logged in as the 'backup' user. *HOWEVER* this is -not- a solution for the OP's "problem", as a skilled, _malicious_, user can change, say, vi(1)'s idea of what executable it should invoke when a '!', or '!!' command is issued.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203130033.q2D0XUwg048729>