If you are using the RBASH and the user has rights for example to call vi, he has the possibility to exit the shell by vi, also a "su exampleuser" would do the job, there are also possibilities to copy /bin/sh...... In this case the only thing i wanted to restrict the user to allow him to become root. Yes i know, the pro and cons about that, i decided that connecting by ssh to a user that has NO rights except su the root user and getting root if i need to change something is a good way.

As described earlier i added (modified) a user

useradd example -m -d /home/example -s /bin/rbash
usermod -s /bin/rbash example
passwd example

Then i edited his bash-profile and set the PATH only to his homedirectory.

vi /home/example/.bash_profile

I changed the part where the path-variable is set, it looks like this now:

# set PATH so it includes user's private bin if it exists
PATH=/home/example
#if [ -d ~/bin ] ; then
#    PATH=~/bin:"${PATH}"
#fi

So this user has absolutely NO rights... cool Last step is to allow him to get root. That's done by creating a script, i named it suroot in /bin that contains the text "/bin/su root", of course you have to give it 755 rights afterwards. The very last step is to crate a link from the user home to the new script.

vi /bin/suroot
chmod 755 /bin/suroot
cd /home/example
ln -s /bin/suroot

I could not find a way to escape from this jailshell, sometimes i have overseen something, if so please let me know.

Yesterday i decided to enable the mailing feature of bacula, to keep informed about backups that did not work.

Normally you can easily configure that in the bacula-dir.conf file, by uncommenting/setting the mailcommand and the email-address.
The default entries look similar to this:

1

mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\"
 -s \"Bacula: %t %e of %c %l\" %r"
mail = root@localhost = all, !skipped

The mailcommand bsmtp is a bacula-builtin and the %r gets replaced with the email-address from "mail".
In this example all mails except the skipped ones get sent to root@localhost.

In my case i could not use bsmtp because i need authentication on the smtp server to send mails, like gmail also needs.
So i had to look for an alternative and i found sendEmail that is also available as Debian package.
sendEmail is a very powerful smtp-command-line tool. The installation on Debian is quite simple.

1

apt-get install sendemail

Now i changed the mailcommand to the following: (you have to put it in one line!)

1

 mailcommand = "/usr/bin/sendEmail -f 
  This e-mail address is being protected from spambots. You need JavaScript enabled to view it
  -t
%r -u \"Bacula: %t %e of %c %l\" -m Intervention needed! -s
smtp.mymailserver.at -o tls=no -xu myusernamer -xp mypassword"

-f is the from address
-t is the target %r gets replaced by bacula with the mail-address defined
-u is the subject that will look like "Bacula: Backup ERROR of HostBacula Full" in the mail.
-m is the mail body, i really dont know how to put the errorlog for this one job in there...
-s is the mailserver
-o is the authentication, if you want it more secure you should use tls
-xu username
-xp password

I choose to use "MailOnError", because i check all jobs and logs on a regular base so i just want a quick inform if an error occured, if you use "mail" then you get also informed about succesfully terminated jobs.

1
2
3

sc create svnserve binpath= "c:\subversion\svnserve.exe --service
    --root c:\repos" displayname= "Subversion" depend= tcpip
    start= auto

it worked out of the box without any troubles.
The only thing that was not working was TortoiseSVN. So... it worked by command line but did not work with TortoiseSVN? Yes.
After trying for hours i uninstalled SlikSVN and tried the CollabNet package. With this package it worked without any troubles.

I really don't know what could be the reason for this. I also found some threads where people had the same problems.
Does anybody out there have hint, why it does not work with SlikSVN?

Another good way to limit the rights of a remote user in linux is to use rbash (restricted bash). Although there are ways to bypass the restrictions it is in my opinion a nice way to protect a user from himself (and my system from this user....).

rbash

example

useradd example -m -d /home/example -s /bin/rbash
usermod -s /bin/rbash example
passwd example

Another nice way to create users on linux that have just rights for scp/ftp/cvs/rdist/rsync is RSSH (restricted ssh).

Example (for debian)

apt-get install rssh

vi /etc/rssh.conf

useradd -m -d /home/heinzi -s /usr/bin/rssh heinzi
usermod -s /usr/bin/rssh heinzi

By default a user in user has a lot of rights, nothing really critical, but why allow him to peak in any config files if he doesn't really need to? So i was looking for a way to limit the rights of a remote user, without the need to chmod a lot of files. The first way i found was to create a jail shell. This is a pretty cool way to limit a user to a handful of commands and prevent him of leaving his home-directory. It works either with SFTP (easy) and SSH (bit more of configuration) and can either be applied to a user or a group. The user is named "heinzi" in this example:

SFTP

user

Match User heinzi
    ChrootDirectory /home/heinzi
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand /usr/lib/openssh/sftp-server

group

  ChrootDirectory /home
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand /usr/lib/openssh/sftp-server

/etc/init.d/ssh restart 

The user should now be limited to his homedirectory.

Here the example for ssh:

SSH

apt-get install sudo debianutils coreutils

cd /usr/local/sbin
wget http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/make_chroot_jail.sh
chmod 700 /usr/local/sbin/make_chroot_jail.sh

vi /usr/local/sbin/make_chroot_jail.sh

cd /home
ln -s . home

make_chroot_jail.sh heinzi /bin/bash /home

vi /etc/ssh/sshd_config

user

Match User heinzi
    ChrootDirectory /home
    AllowTCPForwarding no
    X11Forwarding no

group

  ChrootDirectory /home
  AllowTCPForwarding no
  X11Forwarding no

/etc/init.d/ssh restart 

"java.lang.InstantiationException: jms.xml: port 9240 already in use"

This error can occur if you try to start the oc4j (startinst.bat on windows) and the oc4j was not shutdown with the shutdown script that is delivered by oracle. Just execute the shutdown script (stopinst.bat on Windows). That should solve your problem.

If you want to run XPlanner+ with the security-manager of tomcat turned on, you need to give following permissions, tested with tomcat5:

permission javax.security.auth.AuthPermission "modifyPrincipals";
permission java.net.SocketPermission "127.0.0.1:3306","connect, resolve";
permission java.net.SocketPermission "localhost:9090","connect,resolve";
permission java.lang.RuntimePermission "getProtectionDomain";
permission java.lang.RuntimePermission "shutdownHooks";
permission java.lang.RuntimePermission "accessClassInPackage.org.apache.jasper.el";
permission java.lang.RuntimePermission "accessClassInPackage.org.apache.coyote";
permission java.lang.RuntimePermission "accessClassInPackage.javax.el";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.io.FilePermission 
"/var/lib/tomcat5.5/webapps/xplanner-plus/xplanner-plus-activity.log", "read,write";
permission java.io.FilePermission "*","read";
permission java.io.FilePermission "/usr/share/tomcat5.5/common/-","read";
permission java.io.FilePermission "/usr/share/tomcat5.5/bin/bootstrap.jar", "read";
permission java.io.FilePermission "/usr/share/java/commons-daemon.jar", "read";
permission java.io.FilePermission 
"/var/lib/tomcat5.5/webapps/xplanner-plus/WEB-INF/classes/logging.properties","read";
permission java.util.PropertyPermission "*","read,write";
permission java.net.SocketPermission "jakarta.apache.org:80","connect,resolve";
 

I tested this permissions on Debian Lenny. The xplanner-plus-activity.log is in this path because i changed it manually. Reason is that there seems to be a bug in the log4j configuration i already reported.