Search raisama.net:
raisama.netAs people closer to me may know, my wife and me are buying a new home, an apartment near my current home (that is a rented apartament), and even nearer to the Conectiva-Mandriva office.
I am not exactly buying all of the apartment, but I am financing most of it at a Federal Bank here. The government offer loans at ridiculous rates, for people matching certain criteria. Luckly, I’ve managed to match it and even optmize the parameters of the financing, so that I get most of the price of the apartment lended at these rates.
I would show you the formulas and how I optmized it, but that is not the subject of this post.
I was impressed with the amount of paper I had to sign and bring to the bank. A large list of documents, from me, from the seller, from the apartment. Yesterday I have finally signed the contract with the bank, but the most impressive part of the bureaucratic process was after that. After signing a dozen of forms, I’ve signed three copies of a 14 page contract (I still didn’t read it completely). Then, I had to do some paperwork to finish the process. Here is what I had to do:
10 visits to 9 different places. Wow.
I’ve been thinking on why all this stuff. Why not a simpler process? And, specially, why so much paper? I think there are two (non-exclusive) kind of reasons for this. The first one is simple: stupidity. People are stupid and design inefficient processes, and follow them blindly. This is unquestionable, I guess. But I think there is a more interesting reason: security. It may be not the main reason, and it is not the only one for this inefficient process, but is at least part of the set of valid reasons for it.
I was wondering why not using digital means for all this process. The technology is there, implementing it is even cheaper than having lots of different physical places for doing this stuff. But then I’ve been wondered that on of the things that originate bureaucracy is the need for security. I would really like, for example, to have a simple card that I can use to certify that I agree to the contract, instead of signing lots of paper, and going to notaries so they say “yes, it is his signature”. The same for the registration on the real estate registration notary: why not an online system where I can just pay all the taxes over the internet, and then get the operation done, digitally certified? It would be really nice, but are we able to build a secure system that would do all this stuff?
To me, it seems that it wouldn’t be so secure. On the current process, if you want to fool the system, you need to fool (or buy ;) lots of different people. If one of them see that you are trying to trick the system, then you’ll have no success. Of course, if you don’t convince him that he should let you do it (it is a bit easy if you have lots of money), but that is another story.
What if it could be done digitally, without anyone watching? It would be way too easy to trick the system. The system could do most of the formal checks people do, of course, but the weakest part of the chain is the human bean that, by ignorance, may be fooled to say “yes, I want to do it” to the system, without knowing what he is doing, just like they click on a link on an e-mail message, see a message asking them to give their bank account number and password to update their data on the bank, and they do it. People are Silly.
I guess I’ve just concluded (while I was writing this text) that there is only one reason for this inefficient process: stupidity. But, as we may think, it is not exclusively due to the stupidity from the people that run the inefficient system, but also to the stupidity of the people that wouldn’t know how to properly use a more efficient system. The unanswered question is: which side is more stupid.
8 comentáriosNow, the solution for the problem I described on my previous post.
First, the immediate cause of the problem: permission on /. Simple. When investigating the problem, I’ve checked everything, all directories on the way to the file that the user hadn’t permissions to acces, except the permissions of /. I would never imagine that the permission of the root directory would change unexpectedly. The / had no execution permission for anybody, except its owner. So, everytime a process made setuid() to another user, all filesystem operations failed, because the user wasn’t supposed enter anywhere on the filesystem.
Now the question was: how the hell had the permissions on / changed? That is part of list of things you must never do on your system. I’ve took some time to figure out how it happened. But I remembered some things I’ve did some minutes before the problem appeared, that I didn’t imagine that would cause this.
I was compiling software on a machine, but wanted to install on my machine the software I was building. So, the first thing that came to my mind was: just install it using DESTDIR, and copy the files to your machine. It was just for a quick test, so it seemed to be a good idea.
Let’s go: mkdir /tmp/mysoftware; make install DESTDIR=/tmp/mysoftware; cd /tmp/mysoftware; tar -zcvf /tmp/mysoftware.tgz .. Looks right.
Copied mysoftware.tgz to my machine. cd /; tar -zxvf mysoftware.tgz. It seemed to be a sane thing to do: the only contentes of mysoftware.tgz were files on usr/local. Everything was ok, except that lots of stuff on my machine simply stopped working after I’ve extracted the tarball.
The only problem was: the contents of the tarball weren’t just files on usr/local. There was a evil entry on the file:
drwx------ ehabkost/ehabkost 0 2005-06-13 17:11:33 ./
See? That caused all the problems. I’ve extracted the tarball, this entry was extracted, the permissions of / were changed. Simple.
I’ve told you that it was stupid.
Comente!In the beginning of this week, suddenly my machine here at work started to behave very weirdly. I will try to describe what happened, here.
Monday, about one hour before I going home, mutt suddenly closed the connection with my local IMAP server (I use cyrus-imapd to store my mail on my own machine). The message was something like “IMAP connection terminated unexpectedly”.
I’ve restarted cyrus-imapd. And then, what I’ve seen on the logs was lots of this message:
IOERROR: stat /var/lib/imap/mailboxes.db: Permission denied
Weird, huh? I’ve checked the permissions of /var/lib/imap, /var/lib/imap/*, and so on. There was nothing wrong with them.
Then, I’ve noticed that procmail wasn’t delivering my mail, too. I use procmail+cyrus-deliver to deliver my mail (I had no patience to convert my procmail file to sieve, yet). The message was even worse:
/usr/lib/cyrus-imapd/deliver: error while loading shared libraries: libsasl2.so.2: cannot open shared object file: Permission denied
Permission denied when loading a library? Huh?
Then I’ve noticed that similar problems were happening on some non-root suid binaries. I’ve tried su cyrus -c /some/non-suid/binary, too. Same problem.
stracing it, what I’ve seen was:
19616 setfsuid32(74) = 0
19616 setfsgid32(12) = 0
19616 open("/etc/passwd", O_RDONLY) = -1 EACCES (Permission denied)
19616 open("/etc/ld.so.cache", O_RDONLY) = -1 EACCES (Permission denied)
And lots of other calls returning EACCESS.
On all cases, the problem was the same: just after doing setuid(), all file operations were returning EACCESS. I was confused.
I gave up, and rebooted the machine. Same problem. I went home, and then discovered that I couldn’t even login through ssh from home to my machine.
On the next day, it became even worse: now I couldn’t even login as the ‘ehabkost’ user, that was working before reboot.
I’ve booted with a different kernel, using the Conectiva Linux rescue disk. chrooted to my root partition, and same problem.
More tests: created /chr, as a test chroot. Copied /etc, /bin and /lib to this directory. chrooted there. And, it worked: the problem didn’t happen inside the chroot. Uh, oh.
I thought: “let’s create another partition, copy my root partition there, and test if the problem happens again”. Created a new LV, mounted as /tmproot, cp -xa / /tmproot, chroot /tmproot, and… it didn’t work!. I removed everything from /tmproot, leaving only /etc, /bin and /lib. chrooted there and it didn’t work. I’ve even moved /tmproot/* to /chr, and it was always working on /chr, but not on /tmproot. My conclusion after seeing this was: the problem happens when the root is a mounted LV or partition, but not if it is a subdirectory of a filesystem on a LV or partition.
I’ve lost my patience to track the problem, and recreated the filesystem on my root partition. Copied the contents of the tmproot LV, and the problem vanished. Miracle. My conclusion: there was something very weird with my filesystem (yes, I’ve tried fsck before my first tests, and it reported no errors).
Tuesday, all the truth was revealed to me when I was thinking about the problem. When thinking about what could give EACCESS errors on all filesystem operations, except when running was root, I was enlightened and noticed what caused the problem. Very stupid problem. Until yesterday, I couldn’t even think on how it could happen. Then I’ve discovered that it was my fault.
I won’t tell you what was the problem, neither what caused it, right now. The problem was really simple and easily fixed with a single and simple command. Let’s see if someone can tell what the problem was, or what I forgot to check when tracing the problem.
See the solution and the description of the stupid thing I did on the next post.
2 comentáriosO cafofo novo está na reta final. Semana que vem eu devo estar vendendo minha alma e assinando o contrato.
Aí só falta 17 anos para pagar o financiamento. Depois disso, já poderemos dizer: “É nosso!”. 8)
/me ansioso
6 comentáriosNow that I am on Planet Mandriva, I am considering alternatives to make a multilingual blog. I am starting using categories for that, but I plan to test the multilingual plugin soon.
Disadvantages of the current approach:
Disadvantages I want to avoid when using the multilingual plugin:
