LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 09-21-2007, 06:16 AM   #1
nkd
Member
 
Registered: Oct 2006
Location: india
Distribution: fedora 8, ubuntu 10.10
Posts: 315

Rep: Reputation: 34
keyutils instln


Hi all,
I wish to try out ecryptFs on linux 2.6.22.6.
I have got all the kernel space support configured. Next I downloaded the
userspace utils as tarball . But during make it complained that the keyUtils ver 1.2 or more is required.
I next tried to get the source tarball for keyutils but the make gave some error - a _NR???? var not defined in some ???function. So I dunked the process and downloaded the rpm for keyutils. But it says dependency failed - libkeyutils missing ,etc.
Can someone suggest some way to easily install keyutils correctly on my system so that I can install the user space utils for ecryptFs.
Thanks in advance
nishith
 
Old 09-22-2007, 04:16 PM   #2
1slipperyfish
LQ Newbie
 
Registered: May 2007
Location: wigan
Distribution: mandriva
Posts: 29

Rep: Reputation: 15
is there any way you can copy and paste your errors?? as it would make it easier(for me anyway) to see what the problem is
paul
 
Old 09-23-2007, 03:09 PM   #3
nkd
Member
 
Registered: Oct 2006
Location: india
Distribution: fedora 8, ubuntu 10.10
Posts: 315

Original Poster
Rep: Reputation: 34
Thaks 1slipperyfish,

here is the error I get when I try to make from the source tarball after untarring it :
[root@localhost keyutils-1.2]# make
cc -g -O2 -Wall -UNO_GLIBC_KEYERR -o keyutils.o -c keyutils.c
keyutils.c: In function `add_key':
keyutils.c:39: error: `__NR_add_key' undeclared (first use in this function)
keyutils.c:39: error: (Each undeclared identifier is reported only once
keyutils.c:39: error: for each function it appears in.)
keyutils.c: In function `request_key':
keyutils.c:48: error: `__NR_request_key' undeclared (first use in this function)keyutils.c: In function `__keyctl':
keyutils.c:58: error: `__NR_keyctl' undeclared (first use in this function)
make: *** [keyutils.o] Error 1


What to do ? can you help me now ?

thanks in advance
nishith
 
Old 09-23-2007, 05:51 PM   #4
osor
HCL Maintainer
 
Registered: Jan 2006
Distribution: (H)LFS, Gentoo
Posts: 2,450

Rep: Reputation: 75
Quote:
Originally Posted by nkd View Post
Thaks 1slipperyfish,

here is the error I get when I try to make from the source tarball after untarring it :
[root@localhost keyutils-1.2]# make
cc -g -O2 -Wall -UNO_GLIBC_KEYERR -o keyutils.o -c keyutils.c
keyutils.c: In function `add_key':
keyutils.c:39: error: `__NR_add_key' undeclared (first use in this function)
keyutils.c:39: error: (Each undeclared identifier is reported only once
keyutils.c:39: error: for each function it appears in.)
keyutils.c: In function `request_key':
keyutils.c:48: error: `__NR_request_key' undeclared (first use in this function)keyutils.c: In function `__keyctl':
keyutils.c:58: error: `__NR_keyctl' undeclared (first use in this function)
make: *** [keyutils.o] Error 1


What to do ? can you help me now ?

thanks in advance
nishith
It looks like the linux-headers against which glibc is compiled is too old. You could either upgrade that or put the correct defines in.

If you tell us what arch you use, we can tell you how to fix the defines for the newer system calls.
 
Old 09-24-2007, 06:41 AM   #5
nkd
Member
 
Registered: Oct 2006
Location: india
Distribution: fedora 8, ubuntu 10.10
Posts: 315

Original Poster
Rep: Reputation: 34
hi osor,
I actually donot understand how to find out the arch. so I am sending you the following :-
output of /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 349.191
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 688.12

Next, my kernel lies in the /usr/src/linux/arch/i386/boot dir after compilation. So wud it mean it is a i386 arch ?

Also the gcc I use is :
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)


I however have a libc-2.3.4.so executable in my /lib dir.

Sorry for throwing all that at you.... plz guide me and also if possible explain the arch stuff....
Thanks
nishith
 
Old 09-24-2007, 12:05 PM   #6
osor
HCL Maintainer
 
Registered: Jan 2006
Distribution: (H)LFS, Gentoo
Posts: 2,450

Rep: Reputation: 75
Quote:
Originally Posted by nkd View Post
So wud it mean it is a i386 arch ?
Yes, that is what I meant by what arch you have. So now, you can do one of a few things:
  1. Upgrade your linux headers (and presumably glibc). This is the “permanent” solution.
  2. Patch a certain system-wide file, creating a permanent change which will work when you compile any future version of keyutils or a different program which directly uses the syscalls in question. This is the “permanent” hack.
  3. Patch the keyutils sources to accommodate the system calls. You will have to do something similar every time you download a new keyutils release. This is the “temporary” hack.
I will explicitly give you the temporary hack (since it’s easier). Here is a patch against keyutils-1.2 that should resolve the issue:
Code:
diff -ur keyutils-1.2.a/keyutils.c keyutils-1.2.b/keyutils.c
--- keyutils-1.2.a/keyutils.c	2005-11-28 07:45:08.000000000 -0500
+++ keyutils-1.2.b/keyutils.c	2007-09-24 11:58:59.000000000 -0400
@@ -30,6 +30,10 @@
 
 #define __weak __attribute__((weak))
 
+#define __NR_add_key		286
+#define __NR_request_key	287
+#define __NR_keyctl		288
+
 key_serial_t __weak add_key(const char *type,
 			    const char *description,
 			    const void *payload,
The permanent hack is harder since I cannot give an explicit patch unless I know your kernel headers version (i.e., the output of “grep LINUX_VERSION_CODE /usr/include/linux/version.h”). This becomes more complicated since Redhat backports significant features. Presumably, it might look something like this:
Code:
diff -ur /usr/include/asm/unistd.h.old /usr/include/asm/unistd.h
--- /usr/include/asm/unistd.h.old
+++ /usr/include/asm/unistd.h
@@ -291,14 +291,19 @@
 #define __NR_sys_kexec_load    283
 #define __NR_waitid            284
 #define __NR_sys_setaltroot    285
+#define __NR_add_key           286
+#define __NR_request_key       287
+#define __NR_keyctl            288
 
-#define NR_syscalls 286
-
-/* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
+#define NR_syscalls 289
 
+/*
+ * user-visible error numbers are in the range -1 - -128: see
+ * <asm-i386/errno.h>
+ */
 #define __syscall_return(type, res) \
 do { \
-	if ((unsigned long)(res) >= (unsigned long)(-125)) { \
+	if ((unsigned long)(res) >= (unsigned long)(-(128 + 1))) { \
 		errno = -(res); \
 		res = -1; \
 	} \
 
Old 09-25-2007, 06:23 AM   #7
nkd
Member
 
Registered: Oct 2006
Location: india
Distribution: fedora 8, ubuntu 10.10
Posts: 315

Original Poster
Rep: Reputation: 34
Thanks but stil having problem

Last edited by nkd; 09-25-2007 at 06:33 AM.
 
Old 09-25-2007, 06:31 AM   #8
nkd
Member
 
Registered: Oct 2006
Location: india
Distribution: fedora 8, ubuntu 10.10
Posts: 315

Original Poster
Rep: Reputation: 34
hi osor,
I am sorry I haven't understood the temporary hack too well
Diff finds the difference between keyutils-1.2.a/keyutils.c and keyutils-1.2.b/keyutils.c isn't it ? But I have only one file on my keyutils dir, so was that for you to detect the changes required by me.
anyway I went ahead and opened the keyutils.h file and applied the changes in # define and the function declaration. But make complains about the duplicate add_key declaration :
[root@localhost keyutils-1.2]# make
cc -g -O2 -Wall -UNO_GLIBC_KEYERR -o keyutils.o -c keyutils.c
In file included from keyutils.c:21:
keyutils.h:106: error: conflicting types for 'add_key'
keyutils.h:101: error: previous declaration of 'add_key' was here
keyutils.h:106: error: conflicting types for 'add_key'
keyutils.h:101: error: previous declaration of 'add_key' was here
make: *** [keyutils.o] Error 1


I am sorry, but could you plz help me out by telling which file to modify explicitly.
Thanks
nishith
 
Old 09-25-2007, 06:39 AM   #9
nkd
Member
 
Registered: Oct 2006
Location: india
Distribution: fedora 8, ubuntu 10.10
Posts: 315

Original Poster
Rep: Reputation: 34
sorry osor,
That was really dumb of me
I gave out the solution to my problem when writing back to you. I should just add the define statements to the keyutils.c and not he keyutils.h, isn't it.
I did it and it makes like a breeze .
sorry for the trouble and the unnecessary posts.... ignore the previous messages and thanks a ton.
I will come back if I have any more problems.
By the way what are these __NR_keys for ?

nishith
 
Old 09-25-2007, 11:51 AM   #10
osor
HCL Maintainer
 
Registered: Jan 2006
Distribution: (H)LFS, Gentoo
Posts: 2,450

Rep: Reputation: 75
Quote:
Originally Posted by nkd View Post
I should just add the define statements to the keyutils.c and not he keyutils.h, isn't it.
Yes, that’s it. Also, you don’t have to patch by hand (although in this case there are only three lines). Read up on the patch utility to make your life easier.
Quote:
Originally Posted by nkd View Post
thanks a ton.
No problem.
Quote:
Originally Posted by nkd View Post
By the way what are these __NR_keys for ?
They are numbers for key-management system calls implemented in the kernel around 2.6.11 or so. Since you are running a new (2.6.22) kernel, it knows how to take these system call requests. The only problem is that the headers are old enough (pre 2.6.11) that userspace programs don’t know that the kernel knows what these numbers mean. So you have to tell them (the userspace programs) how to use those system calls. For i386, you can find a list of up-to-date system call numbers here.
 
Old 09-26-2007, 06:40 AM   #11
nkd
Member
 
Registered: Oct 2006
Location: india
Distribution: fedora 8, ubuntu 10.10
Posts: 315

Original Poster
Rep: Reputation: 34
hi osor,
Thanks for explaining that stuff to me .
I am overawed by your knowledge....I mean that.....you are too good!
I have been able to ./configure ecryptfs-utils after I installed keyutils-1.2 on my system. But the make stage is throwing up an error :
In file included from pam_ecryptfs.c:39:
../include/ecryptfs.h:45:2: warning: #warning NETLINK_ECRYPTFS not defined in netlink.h
pam_ecryptfs.c: In function `error':
pam_ecryptfs.c:46: error: `ENOKEY' undeclared (first use in this function)
pam_ecryptfs.c:46: error: (Each undeclared identifier is reported only once
pam_ecryptfs.c:46: error: for each function it appears in.)
pam_ecryptfs.c:50: error: `EKEYEXPIRED' undeclared (first use in this function)
pam_ecryptfs.c:54: error: `EKEYREVOKED' undeclared (first use in this function)
pam_ecryptfs.c:58: error: `EKEYREJECTED' undeclared (first use in this function)make[2]: *** [pam_ecryptfs.lo] Error 1
make[2]: Leaving directory `/opt/ecryptfs-utils-23/src/pam_ecryptfs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/ecryptfs-utils-23/src'
make: *** [all-recursive] Error 1


Does it mean that like in case of keyutils again the headers are out of date ?!?!? Will fixing up the headers solve the problem or something else needs to be done here ?

Thanks for everything
nishith
 
Old 09-26-2007, 01:28 PM   #12
osor
HCL Maintainer
 
Registered: Jan 2006
Distribution: (H)LFS, Gentoo
Posts: 2,450

Rep: Reputation: 75
Quote:
Originally Posted by nkd View Post
Does it mean that like in case of keyutils again the headers are out of date ?!?!?
Yes. In this case it is not the system calls, but a netlink socket type and a few error numbers relating to key management.
Quote:
Originally Posted by nkd View Post
Will fixing up the headers solve the problem or something else needs to be done here
Well, as before, you have three solutions: you can upgrade all your headers (and glibc) through your distribution, you can patch certain system-wide headers, or you can patch the files throwing the errors. The first is the most elegant, but it requires a system-wide upgrade which potentially breaks compiled software. The second is less drastic, but will ensure any future builds of ecryptfs-utils succeed. The third is the easiest, and is what I’ll show here:
Code:
diff -ur ecryptfs-utils-23.a/src/include/ecryptfs.h ecryptfs-utils-23.b/src/include/ecryptfs.h
--- ecryptfs-utils-23.a/src/include/ecryptfs.h	2007-08-20 07:54:16.000000000 -0400
+++ ecryptfs-utils-23.b/src/include/ecryptfs.h	2007-09-26 13:20:34.000000000 -0400
@@ -42,10 +42,30 @@
 #endif
 
 #ifndef NETLINK_ECRYPTFS
-#warning NETLINK_ECRYPTFS not defined in netlink.h
+#warning NETLINK_ECRYPTFS not defined in netlink.h; setting it to 19
 #define NETLINK_ECRYPTFS 19
 #endif
 
+#ifndef ENOKEY
+#warning ENOKEY is not defined in your errno.h; setting it to 126
+#define ENOKEY 126
+#endif
+
+#ifndef EKEYEXPIRED
+#warning EKEYEXPIRED is not defined in your errno.h; setting it to 127
+#define EKEYEXPIRED 127
+#endif
+
+#ifndef EKEYREVOKED
+#warning EKEYREVOKED is not defined in your errno.h; setting it to 128
+#define EKEYREVOKED 128
+#endif
+
+#ifndef EKEYREJECTED
+#warning EKEYREJECTED is not defined in your errno.h; setting it to 129
+#define EKEYREJECTED 129
+#endif
+
 /* Version verification for shared data structures w/ userspace */
 #ifndef ECRYPTFS_VERSION_MAJOR
 #define ECRYPTFS_VERSION_MAJOR 0x00
diff -ur ecryptfs-utils-23.a/src/libecryptfs/key_management.c ecryptfs-utils-23.b/src/libecryptfs/key_management.c
--- ecryptfs-utils-23.a/src/libecryptfs/key_management.c	2007-08-20 07:54:16.000000000 -0400
+++ ecryptfs-utils-23.b/src/libecryptfs/key_management.c	2007-09-26 13:19:06.000000000 -0400
@@ -35,11 +35,6 @@
 #include <sys/stat.h>
 #include "../include/ecryptfs.h"
 
-#ifndef ENOKEY
-#warning ENOKEY is not defined in your errno.h; setting it to 126
-#define ENOKEY 126
-#endif
-
 /**
  * This is the common functionality used to put a password generated key into
  * the keyring, shared by both non-interactive and interactive signature
Remember, you don’t have to patch by hand, you can use the patch utility. For example, if you copy-and-paste the patch to a file named ecrypt.patch, you can do this:
Code:
$ cat > ecrypt.patch << __EOF__
diff -ur ecryptfs-utils-23.a/src/include/ecryptfs.h ecryptfs-utils-23.b/src/include/ecryptfs.h
--- ecryptfs-utils-23.a/src/include/ecryptfs.h	2007-08-20 07:54:16.000000000 -0400
+++ ecryptfs-utils-23.b/src/include/ecryptfs.h	2007-09-26 13:20:34.000000000 -0400
@@ -42,10 +42,30 @@
 #endif
 
 #ifndef NETLINK_ECRYPTFS
-#warning NETLINK_ECRYPTFS not defined in netlink.h
+#warning NETLINK_ECRYPTFS not defined in netlink.h; setting it to 19
 #define NETLINK_ECRYPTFS 19
 #endif
 
+#ifndef ENOKEY
+#warning ENOKEY is not defined in your errno.h; setting it to 126
+#define ENOKEY 126
+#endif
+
+#ifndef EKEYEXPIRED
+#warning EKEYEXPIRED is not defined in your errno.h; setting it to 127
+#define EKEYEXPIRED 127
+#endif
+
+#ifndef EKEYREVOKED
+#warning EKEYREVOKED is not defined in your errno.h; setting it to 128
+#define EKEYREVOKED 128
+#endif
+
+#ifndef EKEYREJECTED
+#warning EKEYREJECTED is not defined in your errno.h; setting it to 129
+#define EKEYREJECTED 129
+#endif
+
 /* Version verification for shared data structures w/ userspace */
 #ifndef ECRYPTFS_VERSION_MAJOR
 #define ECRYPTFS_VERSION_MAJOR 0x00
diff -ur ecryptfs-utils-23.a/src/libecryptfs/key_management.c ecryptfs-utils-23.b/src/libecryptfs/key_management.c
--- ecryptfs-utils-23.a/src/libecryptfs/key_management.c	2007-08-20 07:54:16.000000000 -0400
+++ ecryptfs-utils-23.b/src/libecryptfs/key_management.c	2007-09-26 13:19:06.000000000 -0400
@@ -35,11 +35,6 @@
 #include <sys/stat.h>
 #include "../include/ecryptfs.h"
 
-#ifndef ENOKEY
-#warning ENOKEY is not defined in your errno.h; setting it to 126
-#define ENOKEY 126
-#endif
-
 /**
  * This is the common functionality used to put a password generated key into
  * the keyring, shared by both non-interactive and interactive signature
__EOF__
$ wget http://superb-west.dl.sourceforge.net/sourceforge/ecryptfs/ecryptfs-utils-23.tar.bz2
$ tar xf ecryptfs-utils-23.tar.bz2
$ cd ecryptfs-utils-23
$ patch -p1 < ../ecrypt.patch
patching file src/include/ecryptfs.h
patching file src/libecryptfs/key_management.c
 
Old 09-26-2007, 02:47 PM   #13
nkd
Member
 
Registered: Oct 2006
Location: india
Distribution: fedora 8, ubuntu 10.10
Posts: 315

Original Poster
Rep: Reputation: 34
It worked like a breeze !

I am thrilled and believe me I am amazed by your knowledge.
I was feeling a bit shy to approach you this time .. I Knew what was wrong but just couldnot tell what to do about it ( thanks to all the things you shared with me till now ). When I look back, I think I saved myself a lot of woe and trouble by just approaching you with the problem of compiling the ecryptfs-utils.
Thanks a lot.
Just tell me what should I do to be if only half as knowledgeable as you are about headers and stuffs like that ?
And lastly it is guys like you who are making the linux community rock and the OS a big success and even better than the others.
Thanks and regards to you
nishith
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off




All times are GMT -5. The time now is 12:48 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration