In this post I will put some interesting discoveries using
oVirt engine.
Today I
git’ed
oVirt node sources and going to build it :-) Oops.
I need a
oVirt Engine.
Wait, wait. Not so quick.
cat'ing TODO gave me the following link:
http://wiki.ovirt.org/wiki/Node_Backlog.
Please clone it before diving deeper.
git clone https://github.com/oVirt/ovirt-engine
cd to
ovirt-engine
Do not forget read README.adoc.
What I loved there is: "Build locales requires at least
10240 file descriptors". Good start, IMO.
Blablahblah. Let’s do real stuff.
mvn clean install
Errors ... :-(
Tests in error:
test1(org.ovirt.engine.core.uutils.crypto.EnvelopeEncryptDecryptTest): Illegal key size or default parameters
test2(org.ovirt.engine.core.uutils.crypto.EnvelopeEncryptDecryptTest): Illegal key size
Time to fix.
- Open with eclipse uutils project.
- Import maven project …
CNTL+SHIFT+R EnvelopeEncryptDecryptTest
Problem one: no header of the file. You know - copyright, license etc.
Problem two: names of the tests:
test1,
test2 … not bad, very creative!
Solution 1:
Most likely you don't have the unlimited strength file installed now.
Download and install:
Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 Download. Accept and download. 8 means - Java 8.
Install the file in
${java.home}/jre/lib/security/
Quotation:
“In case you later decide to revert to the original "strong" but limited policy versions, first make a copy of the original JCE policy files (US_export_policy.jar and local_policy.jar). Then replace the strong policy files with the unlimited strength versions extracted in the previous step. The standard place for JCE jurisdiction policy JAR files is:
/lib/security [Unix]
\lib\security [Windows]"
Solution 2:
Change 256 to 128 - length of the key to be generated, in
assertArrayEquals(
test,
EnvelopeEncryptDecrypt.decrypt(
entry,
EnvelopeEncryptDecrypt.encrypt(
"AES/OFB/PKCS5Padding",
256,
entry.getCertificate(),
100,
test
)
)
);
Now let’s rerun:
mvn clean install
Next station is: Common utilities.
Import utils to Eclipse.
Next Error ...
testCanReadFile(org.ovirt.engine.core.utils.servlet.ServletUtilsTest): We should not be able to read this file.
The problem is:
/etc/securetty does exist.
Solution 1: delete it … however be aware of: "/etc/securetty is consulted by pam_securetty module to decide from which virtual terminals (ttyS) root is allowed to login from. In the past, /etc/securetty was consulted by programs like login directly, but now PAM handles that. So changes to /etc/securetty will affect anything using PAM with a configuration file that uses pam_securetty.so. So, only the login program is affected by default. /etc/pam.d/login is used for local logins and /etc/pam.d/remote is used for remote logins (like telnet).
The primary entry types and their affects are as follows:
If /etc/securetty doesn't exist, root is allowed to login from any tty
If /etc/securetty exist and is empty, root access will be restricted to single user mode or programs that are not restricted by pam_securetty (i.e. su, sudo, ssh, scp, sftp)
if you are using devfs (a deprecated filesystem for handling /dev), adding entries of the form vc/[0-9]* will permit root login from the given virtual console number
if you are using udev (for dynamic device management and replacement for devfs), adding entries of the form tty[0-9]* will permit root login from the given virtual console number
listing console in securetty, normally has no effect since /dev/console points to the current console and is normally only used as the tty filename in single user mode, which is unaffected by /etc/securetty
adding entries like pts/[0-9]* will allow programs that use pseudo-terminals (pty) and pam_securetty to login into root assuming the allocated pty is one of the ones listed; it's normally a good idea not to include these entries because it's a security risk; it would allow, for instance, someone to login into root via telnet, which sends passwords in plaintext (note that pts/[0-9]* is the format for udev which is used in RHEL 5.5; it will be different if using devfs or some other form of device management)".
Solution 2: probably need to change test. Ask community.
file = new File("/etc/securetty");
// may I change it or there is some hidden logic.
assertFalse("We should not be able to read this file.", ServletUtils.canReadFile(file));
Some interesting stuff how to use if user is not root ...
// Make sure the user is not root
// This tests relies on EXISTING files which only root can access
String userName = System.getProperty("user.name");
assumeTrue(!"root".equals(userName));
Guys, sorry for touching your feelings however we are on Linux. Current user can be any user that named differently than "root" but he can have permissions as a root, can be in admin group etc.
What I mean here, it’s not real checking if user is root or not.
