Thread: cgi with postgres
hey folks,
this is a security issue i'd like to get some info
on, i'm sure it's more with cgi than postgres, but
heck.
issue: how to secure cgi's that access postgres
problem: passwords for postgres database are stored
in plain text in scripts. (lets assume, perl,
not a compiled language)
points:
make cgi dir 711
big deal, they can get the name of the file
from the web, and copy it.
set an obscure cgi script alias in apache
big deal, they can read the cgi conf file.
this is assuming they already have an account
on the machine, something that cannot be ruled
out.
question in short: how to make perl accessing databases
more secure, so any jack can't modify a database.
thanks in advance.
Jeff MacDonald
jeff@hub.org
===================================================================
So long as the Universe had a beginning, we can suppose it had a
creator, but if the Universe is completly self contained , having
no boundry or edge, it would neither be created nor destroyed
It would simply be.
===================================================================
On Fri, Jan 14, 2000 at 04:55:02PM -0400, Jeff MacDonald wrote: > this is a security issue i'd like to get some info > on, i'm sure it's more with cgi than postgres, but > heck. > First off, if the server is set up correctly a casual user should not be able to browse the cgi-bin directory and see your code. I'm not sure what server you are creating your scripts on, but if it is Apache and mod_perl is available to you then this is even better. You can create a handler in mod_perl for a "pseudo-directory" and hide your code that way. However, as I said in my first paragraph this should not be necessary as normally web browsers can't browse the cgi-bin directory anyway and your cgi-script should just send back to the browser html code and not the perl code itself. Unless something is very very wrong.... -- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peter L. Berghold Peter@Berghold.Net "Linux renders ships http://www.berghold.net NT renders ships useless...."
* Jeff MacDonald <jeff@hub.org> [000114 13:38] wrote: > hey folks, > > this is a security issue i'd like to get some info > on, i'm sure it's more with cgi than postgres, but > heck. > > issue: how to secure cgi's that access postgres > > problem: passwords for postgres database are stored > in plain text in scripts. (lets assume, perl, > not a compiled language) > > points: > make cgi dir 711 > big deal, they can get the name of the file > from the web, and copy it. how about sourcing a conf file that's in a 700 dir? > > set an obscure cgi script alias in apache > big deal, they can read the cgi conf file. > > this is assuming they already have an account > on the machine, something that cannot be ruled > out. > > question in short: how to make perl accessing databases > more secure, so any jack can't modify a database. > > thanks in advance. > > Jeff MacDonald > jeff@hub.org > -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
alfred, that seems like a very reasonable solution, in regard to the other chaps responce, i'm not worried about web users anyway, cause they can't see the perl source. it's users on the system i'd like to protect against. On Fri, 14 Jan 2000, Alfred Perlstein wrote: > * Jeff MacDonald <jeff@hub.org> [000114 13:38] wrote: > > hey folks, > > > > this is a security issue i'd like to get some info > > on, i'm sure it's more with cgi than postgres, but > > heck. > > > > issue: how to secure cgi's that access postgres > > > > problem: passwords for postgres database are stored > > in plain text in scripts. (lets assume, perl, > > not a compiled language) > > > > points: > > make cgi dir 711 > > big deal, they can get the name of the file > > from the web, and copy it. > > how about sourcing a conf file that's in a 700 dir? > > > > > set an obscure cgi script alias in apache > > big deal, they can read the cgi conf file. > > > > this is assuming they already have an account > > on the machine, something that cannot be ruled > > out. > > > > question in short: how to make perl accessing databases > > more secure, so any jack can't modify a database. > > > > thanks in advance. > > > > Jeff MacDonald > > jeff@hub.org > > > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > Jeff MacDonald jeff@hub.org =================================================================== So long as the Universe had a beginning, we can suppose it had a creator, but if the Universe is completly self contained , having no boundry or edge, it would neither be created nor destroyed It would simply be. ===================================================================
Jeff MacDonald wrote: > > hey folks, > > this is a security issue i'd like to get some info > on, i'm sure it's more with cgi than postgres, but > heck. > > issue: how to secure cgi's that access postgres > > problem: passwords for postgres database are stored > in plain text in scripts. (lets assume, perl, > not a compiled language) > > points: > make cgi dir 711 > big deal, they can get the name of the file > from the web, and copy it. > > set an obscure cgi script alias in apache > big deal, they can read the cgi conf file. > > this is assuming they already have an account > on the machine, something that cannot be ruled > out. > > question in short: how to make perl accessing databases > more secure, so any jack can't modify a database. > > thanks in advance. > > Jeff MacDonald > jeff@hub.org I'm not sure if this is definitive - hackers are very clever, but this SHOULD do it: 1. httpd runs as user 'nobody' 2. 'nobody' doesn't have a shell account (shell = /bin/false) 3. no one can 'su' to 'nobody', except root (obviously) 4. pg_hba.conf allows only local connections (127.0.0.1) 5. the postmaster isn't running with -i 6. 'nobody' owns the database and has granted privileges to only those other users as appropriate 7. The password (as added protection) is in some file readable by user 'nobody' only. Hope that helps, Mike Mascari
* Jeff MacDonald <jeff@hub.org> [000114 14:07] wrote: > alfred, that seems like a very reasonable solution, > > in regard to the other chaps responce, i'm not worried > about web users anyway, cause they can't see the perl > source. it's users on the system i'd like to protect > against. I'm not sure what you mean, but there is a problem, unless you execute the scripts as a user other than the default cgi user then you may run into problems because then people can craft a cgi and run it through the server to gain access to the 700 dir, you'll either need some sort of setuid (to a special user, not root) or use some sort of cgiwrapper. -Alfred > > On Fri, 14 Jan 2000, Alfred Perlstein wrote: > > > * Jeff MacDonald <jeff@hub.org> [000114 13:38] wrote: > > > hey folks, > > > > > > this is a security issue i'd like to get some info > > > on, i'm sure it's more with cgi than postgres, but > > > heck. > > > > > > issue: how to secure cgi's that access postgres > > > > > > problem: passwords for postgres database are stored > > > in plain text in scripts. (lets assume, perl, > > > not a compiled language) > > > > > > points: > > > make cgi dir 711 > > > big deal, they can get the name of the file > > > from the web, and copy it. > > > > how about sourcing a conf file that's in a 700 dir? > > > > > > > > set an obscure cgi script alias in apache > > > big deal, they can read the cgi conf file. > > > > > > this is assuming they already have an account > > > on the machine, something that cannot be ruled > > > out. > > > > > > question in short: how to make perl accessing databases > > > more secure, so any jack can't modify a database. > > > > > > thanks in advance. > > > > > > Jeff MacDonald > > > jeff@hub.org > > > > > > > -- > > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > > > Jeff MacDonald > jeff@hub.org > > =================================================================== > So long as the Universe had a beginning, we can suppose it had a > creator, but if the Universe is completly self contained , having > no boundry or edge, it would neither be created nor destroyed > It would simply be. > =================================================================== > -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
On Fri, 14 Jan 2000, Jeff MacDonald wrote:
> hey folks,
>
> this is a security issue i'd like to get some info
> on, i'm sure it's more with cgi than postgres, but
> heck.
>
> issue: how to secure cgi's that access postgres
>
> problem: passwords for postgres database are stored
> in plain text in scripts. (lets assume, perl,
> not a compiled language)
>
> points:
> make cgi dir 711
> big deal, they can get the name of the file
> from the web, and copy it.
>
> set an obscure cgi script alias in apache
> big deal, they can read the cgi conf file.
Side point ... why isn't the apache conf file secure? Only user root
needs to be able to read it, no?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Hi, Take a look at : Python : http://www.python.org/ There is an adapteur to Postgresql ==> Pygresql This is GREAT for Unix (Linux) cgi with Postgresql... Just for information. Emmanuel. Le ven, 14 jan 2000, vous avez �crit : > hey folks, > > this is a security issue i'd like to get some info > on, i'm sure it's more with cgi than postgres, but > heck. > > issue: how to secure cgi's that access postgres > > problem: passwords for postgres database are stored > in plain text in scripts. (lets assume, perl, > not a compiled language) > ***
On 2000-01-14, Alfred Perlstein mentioned: > > issue: how to secure cgi's that access postgres > > > > problem: passwords for postgres database are stored > > in plain text in scripts. (lets assume, perl, > > not a compiled language) > > > > points: > > make cgi dir 711 > > big deal, they can get the name of the file > > from the web, and copy it. > > how about sourcing a conf file that's in a 700 dir? Security through obscurity is little security indeed. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On 2000-01-14, The Hermit Hacker mentioned: > Side point ... why isn't the apache conf file secure? Only user root > needs to be able to read it, no? Huh? You run apache as root? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
* Peter Eisentraut <peter_e@gmx.net> [000116 09:30] wrote: > On 2000-01-14, Alfred Perlstein mentioned: > > > > issue: how to secure cgi's that access postgres > > > > > > problem: passwords for postgres database are stored > > > in plain text in scripts. (lets assume, perl, > > > not a compiled language) > > > > > > points: > > > make cgi dir 711 > > > big deal, they can get the name of the file > > > from the web, and copy it. > > > > how about sourcing a conf file that's in a 700 dir? > > Security through obscurity is little security indeed. I don't see how using the unix permissions as a form of ACL is security through obscurity... or do you chmod 644 /etc/shadow on your boxes? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
Peter Eisentraut wrote: > > On 2000-01-14, Alfred Perlstein mentioned: > > > > issue: how to secure cgi's that access postgres > > > > > > problem: passwords for postgres database are stored > > > in plain text in scripts. (lets assume, perl, > > > not a compiled language) > > > > > > points: > > > make cgi dir 711 > > > big deal, they can get the name of the file > > > from the web, and copy it. > > > > how about sourcing a conf file that's in a 700 dir? > > Security through obscurity is little security indeed. 1. If anybody can read your web page, well, then, you would need to make a "reader" account in your DBMS. That way, anybody can get the username and password, and it may not matter. As long as this user only has perms to the database (as in, no shell, no other perms on the box), it's about as secure as any other service that passes user/pass over the 'net in readable form.... 2. Deeper accounts can be controled via .htaccess, via apache. Again, this has holes, but now the potential hacker has two hoops to jump through. 3. Access to specific virtual hosts can be controlled via packet filtering, for more secure connections to an admin page. Yet another hoop. 4. Security through obscurity _can_ be of great value, if your threat scenario is primarily individuals who wouldn't know where to look, or what to look for. If your threat scenario includes individuals who do have that skill level, yup, it's not that much protection. It's like hiding the lock on a door. It's provide security against lock pickers, but no security against the guy with a sledge hammer. A hoop for those with little imagination or knowledge.... Security is not something you can program, buy, or build, it's a mindset. For each hoop you require users to jump through, it's another hoop for a hacker to jump through. Since you _will_ be hacked, by somebody, eventually, you have to balance the level of security with the level of *value* it offers. For example, disabling cgi's helps quite a bit, from a security standpoint, but it makes users cranky. Is that crankyness worth the security of removing all cgi's? If your transactions are worth several thousand a day, of course it is. Are your databases so valuable that you don't want to allow users write access? Don't put them on writable media. Do you need to guarantee that only specific users have access to specific transactions in a specific database? Then cut the cord on internet access, entirely. Back to the original question: >issue: how to secure cgi's that access postgres For *absolutely secure* environments, remove the cgi's, erase the database, take the box in back, and burn it, then crush it into little bits, then sprinkle the ashes over no less than a 300 km radius, in non-equal distribution. ;-) For slightly less security, you should follow two basic, old-school rules: Something you know, and something you have. For each level of security, you should require at least one measure of each. For vanilla access, they would *know* where the server is, and *have* one pasword. More secure: They would *know* a non-htttp-linked, non-listed, CGI file to access, and *have* a specfic IP they are coming from. Next, maybe knowing another access code, and having a stored cookie which is checked against... and on, and on, so by the time they have a high level of access, they've managed to use passwords, RSA keys, their IP, a fingerprint, an eyeball scan..... but it's still not quite as secure as destroying all of the data. :-) Up to that point, it's just a matter of making enough hoops to jump through that it keeps most of your threat assesments at bay, and using them in an _additive_ fashion. Additive? Well, a retinal scan and password combo is only two hoops, but a retinal scan, and password, and RSA key, and initiating IP, and facial scan, and tunneled session, is 6 things a cracker has to break, in the right order, in order to get in. So you have to balance how much security you need versus how many hoops you want to make, as setting up 20+ boxes, in series, to use a SELECT statement, may be a bit absurd for your application. :-) I've done it for giggles, performance was not the best, but it worked well enough that it was pretty much impenetrable from over the internet. Only took two or three minutes to pass a select staement through, and half an hour or so to return a few rows... <g> HTH, -Ronabop
* Ron Chmara <ron@Opus1.COM> [000116 16:18] wrote: > Peter Eisentraut wrote: > > > > On 2000-01-14, Alfred Perlstein mentioned: > > > > > > issue: how to secure cgi's that access postgres > > > > > > > > problem: passwords for postgres database are stored > > > > in plain text in scripts. (lets assume, perl, > > > > not a compiled language) > > > > > > > > points: > > > > make cgi dir 711 > > > > big deal, they can get the name of the file > > > > from the web, and copy it. > > > > > > how about sourcing a conf file that's in a 700 dir? > > > > Security through obscurity is little security indeed. > > 1. If anybody can read your web page, well, then, you > would need to make a "reader" account in your DBMS. > That way, anybody can get the username and password, > and it may not matter. As long as this user only has > perms to the database (as in, no shell, no other perms > on the box), it's about as secure as any other service > that passes user/pass over the 'net in readable form.... > > 2. Deeper accounts can be controled via .htaccess, > via apache. Again, this has holes, but now the potential > hacker has two hoops to jump through. > > 3. Access to specific virtual hosts can be controlled > via packet filtering, for more secure connections to > an admin page. Yet another hoop. > > 4. Security through obscurity _can_ be of great value, > if your threat scenario is primarily individuals who > wouldn't know where to look, or what to look for. If > your threat scenario includes individuals who do have > that skill level, yup, it's not that much protection. > It's like hiding the lock on a door. It's provide security > against lock pickers, but no security against the guy > with a sledge hammer. A hoop for those with little > imagination or knowledge.... All these options don't take into account that perhaps you don't want people _on the same box_ to be able to even read arbitrary things from your database. Sure you can protect the tables from modification via postgresql's internal ACL system, however what if you wish to deny read access as well? For this you need a file with an ACL prevents other _local users_ from reading it. This is _not_ security through obscurity, this is basic ACL control. Again, figure a way to 'protect' your shadow password database without relying on an external auth server. > Security is not something you can program, buy, or build, > it's a mindset. For each hoop you require users to jump > through, it's another hoop for a hacker to jump through. > Since you _will_ be hacked, by somebody, eventually, you > have to balance the level of security with the level of > *value* it offers. For example, disabling cgi's helps quite > a bit, from a security standpoint, but it makes users > cranky. Is that crankyness worth the security of removing > all cgi's? If your transactions are worth several thousand > a day, of course it is. Are your databases so valuable that > you don't want to allow users write access? Don't put > them on writable media. Do you need to guarantee that > only specific users have access to specific transactions > in a specific database? Then cut the cord on internet access, > entirely. > > Back to the original question: > >issue: how to secure cgi's that access postgres > > For *absolutely secure* environments, remove the cgi's, erase > the database, take the box in back, and burn it, then crush it > into little bits, then sprinkle the ashes over no less than a > 300 km radius, in non-equal distribution. ;-) > > For slightly less security, you should follow two basic, old-school > rules: Something you know, and something you have. For each level > of security, you should require at least one measure of each. For > vanilla access, they would *know* where the server is, and *have* one > pasword. More secure: They would *know* a non-htttp-linked, non-listed, > CGI file to access, and *have* a specfic IP they are coming from. Next, > maybe knowing another access code, and having a stored cookie > which is checked against... and on, and on, so by the time they have > a high level of access, they've managed to use passwords, RSA keys, > their IP, a fingerprint, an eyeball scan..... but it's still not quite as > secure as destroying all of the data. :-) Up to that point, it's just > a matter of making enough hoops to jump through that it keeps > most of your threat assesments at bay, and using them in an > _additive_ fashion. > > Additive? Well, a retinal scan and password combo is only > two hoops, but a retinal scan, and password, and RSA key, and > initiating IP, and facial scan, and tunneled session, is 6 things > a cracker has to break, in the right order, in order to get in. So > you have to balance how much security you need versus how many > hoops you want to make, as setting up 20+ boxes, in series, to > use a SELECT statement, may be a bit absurd for your application. > :-) I've done it for giggles, performance was not the best, but > it worked well enough that it was pretty much impenetrable > from over the internet. Only took two or three minutes to pass > a select staement through, and half an hour or so to return > a few rows... <g> I'd say these are good examples of security through absurdity, interesting to research, but as implied from the responce times of this system: not usable. sorry, :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
Alfred Perlstein wrote: > * Ron Chmara <ron@Opus1.COM> [000116 16:18] wrote: Snip_> Of security items..... > All these options don't take into account that perhaps you don't > want people _on the same box_ Well, I assumed that web clients, using cgi, was the "Subject:", so I didn't adrdress it. :-) > to be able to even read arbitrary > things from your database. Sure you can protect the tables from > modification via postgresql's internal ACL system, however what > if you wish to deny read access as well? > For this you need a file with an ACL prevents other _local users_ > from reading it. Hm. If they cannot read the file, how do they read it for access? :-) If they _can_ read a component for access, you already have an item to be eploited, again, it's about finding _balance_ in one's access needs. The only secure server is a non-existant one. > This is _not_ security through obscurity, this is basic ACL control. Which is insecure to attacks from anything that uses it. :-) > Again, figure a way to 'protect' your shadow password database > without relying on an external auth server. Completely protected? On a single server? Can't be done. Relatively protected? Sure. But it's not "secure", it's "relatively secure". Snip_> > >. For > > vanilla access, they would *know* where the server is, and *have* one > > pasword.... > > So > > you have to balance how much security you need versus how many > > hoops you want to make, as setting up 20+ boxes, in series, to > > use a SELECT statement, may be a bit absurd for your application. >> I'd say these are good examples of security through absurdity, > interesting to research, but as implied from the responce times > of this system: not usable. > sorry, :) Perhaps you missed the point behind starting with something extremely insecure (such as a single ACL, as you propose, and I started with something as inherently insucre as that) , and scaling up to absurdly slow, hard to break, but still insecure: There's no such thing as a secure server. So you have to find balance, knowing that whatever you do is insecure in *some* way, and relatively secure in other ways. -Ronabop
ok.
lets get back to the point, i'm not worried about webusers,
so .htaccess is not an issue.
this all arouse when one of hub's clients who runs a course
evaluation system asked
'what's to stop someone from logging in to hub, writing a script
with my name in user=user in the dbi::connect function. then
making it enter a bunch of bogus data.'
at first i thought gee well just put a passwd on the database,
then i thought, gee that's stupid since it's stored in plain text.
======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================
"Jeff MacDonald " wrote: > 'what's to stop someone from logging in to hub, writing a script > with my name in user=user in the dbi::connect function. then > making it enter a bunch of bogus data.' > at first i thought gee well just put a passwd on the database, > then i thought, gee that's stupid since it's stored in plain text. Depends on how you're set up. You can use host based authentification, so only valid machines can make changes. You can shut out shell accounts on the machine, and then use the host's username/pass function for connection. You can use postgres crypt'ed passwords, which doesn't store passwords at all, it stores a block of zeros encrypted using the password.... at least on the machine itself, not in the CGI's... (Yes, I'm rambling about other issues, but I'll get there...) If you're only requiring one username, one password, for a file everybody has access to, well, yes, that's a problem. Which is why password files usually have permissions on them, so : -rw------- 1 postgres demigods 8192 Jan 7 11:55 pg_shadow can only be read/written by user postgres, group demigods. See: http://www.postgresql.org/doxlist.html for a rough overview of how this is supposed to work.. (Still rambling, not about scripted, stored, user/pass access yet) Yes, yes, you can have connections that are username only. You can have username and password, in a cgi, which is why you *don't use real, powerful, usernames and passwords in scripts*. You use things like www or nobody, which write to temporary tables. Which are then inspected for accuracy, or validated, or verified. If your question is framed as "when I give others access into the bank, how do I know they won't steal money?", the response is "by not letting them near the real money". You set up a user for the db that has the _bare_ minimum, and you never, ever, use a cgi. or a script, that allows more rights to be granted. Put another way: It's a bad move to have suid root programs available to the regular users for the same reason... A better metaphor might be: You don't leave your housekeys at the front door for the mailman to deliver the mail. You may have a locked mailbox, and when you want to move the mail, you unlock the box, and _then_ move it. The user doesn't have privleges to dump bad data into the secure tables, only insecure tables. HTH, -Bop
On Friday 14 January 2000, at 16 h 55, the keyboard of Jeff MacDonald <jeff@hub.org> wrote: > make cgi dir 711 > big deal, they can get the name of the file > from the web, and copy it. My CGIs sources a config file, in mode 700, only readable by 'www' (the user which executes Apache). I adopted this after a CGI was inadvenrdently made available on the Web, in source form :-) If you have CGI authors you do not trust, have two Apache, with different IDs. > this is assuming they already have an account > on the machine, something that cannot be ruled > out. Unix file protections are enough against local users.
> My CGIs sources a config file, in mode 700, only readable by 'www' (the user > which executes Apache). this option works, but not well if the user isn't root. Jeff MacDonald jeff@hub.org =================================================================== So long as the Universe had a beginning, we can suppose it had a creator, but if the Universe is completly self contained , having no boundry or edge, it would neither be created nor destroyed It would simply be. ===================================================================
On Monday 17 January 2000, at 11 h 18, the keyboard of Jeff MacDonald <jeff@hub.org> wrote: > > My CGIs sources a config file, in mode 700, only readable by 'www' (the user > > which executes Apache). > > this option works, but not well if the user isn't root. Can you elaborate? Of course, it works well and of course, the actual user is not root.
normal users are not allowed to chown files to oterh users.. On Mon, 17 Jan 2000, Stephane Bortzmeyer wrote: > On Monday 17 January 2000, at 11 h 18, the keyboard of Jeff MacDonald > <jeff@hub.org> wrote: > > > > My CGIs sources a config file, in mode 700, only readable by 'www' (the user > > > which executes Apache). > > > > this option works, but not well if the user isn't root. > > Can you elaborate? Of course, it works well and of course, the actual user is not root. > > > Jeff MacDonald jeff@hub.org =================================================================== So long as the Universe had a beginning, we can suppose it had a creator, but if the Universe is completly self contained , having no boundry or edge, it would neither be created nor destroyed It would simply be. ===================================================================
This really doesn't have anything to do with Postgres, but you guys may want to look into the cgi-wrapper addon that comes with Apache. I haven't used it myself, but from what I understand it does a setuid to the user whose home directory the CGI is in before executing it, thus having the same file access permissions as that user. Then it doesn't matter if other people can run CGI scripts or have shell access, as unless they have the password for the account of the CGI, they can't read it (as long as you aren't an idiot in setting the file permissions.) PHP3 has a similar ability built in that can be turned on via the php3.ini file. The problem with CGI security isn't so much a matter of people getting shell access and playing around, it's more along the lines of writing a CGI that executes a program such as find or cat as the web user, which would enable them to list and display all the CGI's on the system, and their config files. At 12:02 PM 1/17/00, Stephane Bortzmeyer wrote: >On Monday 17 January 2000, at 11 h 18, the keyboard of Jeff MacDonald ><jeff@hub.org> wrote: > > > > My CGIs sources a config file, in mode 700, only readable by 'www' > (the user > > > which executes Apache). > > > > this option works, but not well if the user isn't root. > >Can you elaborate? Of course, it works well and of course, the actual user >is not root. > > > > >************