From: Krischan Jodies (Krischan.Jodies_at_SerNet.DE)
Date: Mon 04 Feb 2002 - 20:06:49 GMT
Am Montag, 4. Februar 2002 17:01 schrieb Jacques Gelinas:
> First time I hear this. I HAS to work.
I have an idea what the reason could be: Maybe the different distributions
use buggy sources for their useradd.
We have the same problem on a SuSE 7.3.
Our vserver /etc Directorys are completly unique for every vserver, we do not
unify in the common way, instead we mount --bind /usr /bin /sbin /lib from a
master partition in every vserver. So there are no special flags on any file
in the vserver.
dynip:~ # ./showattr /etc/passwd
/etc/passwd 00000000
Lutz Pressler noticed the same problem in another place:
krischan_at_dynip:~> mail
Mail version 8.1 6/6/93. Type ? for help.
"/var/mail/krischan": 1 message 1 new
>N 1 root_at_dynip.sernet.de Mon Feb 04 19:45 14/486 "test"
& q
Unable to lock mailbox: Permission denied
I straced useradd and found this difference between a "normal"
linux useradd and ctx-6:
[normal linux]
umask(0777) = 022
open("/etc/passwd+", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
umask(022)
[...]
[ctx-6]
umask(0777) = 022
open("/etc/passwd+", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES
(Permission denied)
umask(022) = 0777
write(2, "useradd: cannot rewrite password"..., 38useradd: cannot rewrite
password file
) = 38
open() while using umask 0777 delivers EACCES even if you are root.
A little test program strips the problem down:
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
int main ()
{
int fd;
umask(0777);
if ((fd = open("testfile",O_WRONLY|O_CREAT|O_TRUNC, 0666)) < 0) {
printf("%s\n",strerror(errno));
}
printf("%d\n",fd);
}
If you try it on in the main server:
server[0]:~ # rm testfile
server[0]:~ # ./test
3
server[0]:~ # ./test
3
server[0]:~ # uname -a
Linux server 2.4.17ctx-6 #1 Wed Jan 30 14:31:55 CET 2002 i686 unknown
server[0]:~ #
-> root may open the file with permission 0000 wether the file exists or not.
in the vserver:
dynip[30]:~ # ./test
Permission denied
-1
dynip[30]:~ # ls -l testfile
---------- 1 root root 0 Feb 4 20:39 testfile
dynip[30]:~ # rm testfile
rm: remove write-protected file `testfile'? y
dynip[30]:~ # ./test
Permission denied
-1
dynip[30]:~ #
-> root must not open the file with permission 0000 under any circumstances
It looks a little different in the main server when you are not root:
test_at_server:~> rm testfile
rm: remove write-protected file `testfile'? y
test_at_server:~> ./test
3
test_at_server:~> ./test
Permission denied
-1
test_at_server:~>
-> It works for a normal user if the file did not exist before.
So the point in a vserver environment is, that root gets permission denied
even when the file did _not_ exist before and is tried to be opened with file
mode 0000.
The not working code in the mail command tries a similar open before it fails:
open("/var/mail/.dynip.4f490", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_SYNC, 0) =
-1 EACCES (Permission denied)
(unchanged umask but mode 0)
Any idea which dropped capability this might be? Perhaps it has something to
do with your chroot hack?
Please try a strace on your redhat / mandrake useradd to see what happens
when /etc/passwd+ is openend with umask 0777. I will attach my straces of
useradd and mail.
I would assume, that if this idea really is right, the bug is located in the
programs that open files without sufficent permission to write into them (and
afterwards are surprised that they really can't write) and not the
kernel/ctx-patch. (But of course we would be happy if you find a way to fix
this anyways :-))
Thanks,
Krischan
-- Service Network GmbH, mailto:kjodies_at_SerNet.DE, http://www.SerNet.DE phone: +49-551-370000-0, fax: +49-551-370000-9