t;untrusted". Everything seems to be working fine.
Oh, and I've enabled process accounting. If a user does indeed find a
way to execute a restricted command without permission, I'll find out
about it.
-Stephen Le
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
;what if" factors by choosing the most
effective means to accomplish what I want done. No method is perfect,
but some methods are certainly better than others.
-Stephen Le
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
it, some easier than others depending
> on what's in /usr/local/rbin.
This won't prevent users from executing banned commands with Perl
scripts called by Apache. I'm opposed to using rbash for this reason
and because some users might want to use a non-bash shell.
-Stephen Le
--
To
They might be able to accomplish what I need, but I'll
have to read more of the documentation.
-Stephen Le
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ode statically and exectute that remotely.
>
> No need for C. Perl suffices.
I should be able to restrict a user's Perl scripts using Apache's
suEXEC. I don't see how a user would be able to remotely execute a
compiled C program outside of their priviledges.
-Stephen Le
--
To U
mands available on the system, though. I might also
want to allow another set of users to be able to run the commands
unavailable to normal users.
In other words, I'd like to restrict normal users more than the
default permissions setup.
-Stephen Le
--
To UNSUBSCRIBE, email to [
oot, but that's really
impractical...
> Use of chroot with bash started as rbash sems to be what you need.
>
> Or use of rbash with with PATH pointing to custom location where
> commands exist.
See the example above. Users would still be able to upload their own
Perl scripts and
needs. A vserver would only be
more complicated. Furthermore, considering the number of users I plan
on having, it'd also be impractical from a resource standpoint.
I'd like to implement these user limitations with minimal kernel modification.
-Stephen Le
--
To UNSUBSCRIBE, email to [EMAI
ds. Besides, telling users to prefix every command
they run with 'sudo' would be awkward and cumbersome.
-Stephen Le
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ess
to if they write a Perl script calling one of the banned commands and
getting Apache to execute that script. In other words, would the
script execute with the script owner's priviledges or with Apache's
priviledges?
Thanks,
Stephen Le
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
uldn't be able to execute. In regards to the latter method, would
it be possible for me to change the group ownership of the commands I
don't want users to have access to and revoke execute permission from
that group?
Thanks,
Stephen Le
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
vsftpd with a MySQL authentication backend.
Thanks,
Stephen Le
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
> I think your should try openvpn http://www.openvpn.org .
>
Although OpenVPN is a really nice and easy to setup solution, it uses
SSL tunneling, rather than IPSEC encryption.
>
> I think your should try openvpn http://www.openvpn.org .
>
Although OpenVPN is a really nice and easy to setup solution, it uses
SSL tunneling, rather than IPSEC encryption.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
14 matches
Mail list logo
