Allow root folder change - ASAP

[RWF]

In NodeWorx under SiteWorx "Shell Users" one can change all the user's shells, EXCEPT root!

I need to be able to change the root user's shell.

[RWF]

And for that matter an option to disallow login by root too!

[IWorx-Paul]

RWF, you really don't want to disable root's shell. That ability is disabled in NodeWorx because it is a bad idea. If this setting was enabled in NodeWorx I guarantee there would be an endless stream of users locking themselves out of their server and blaming us.

Disallowing root logins VIA SSH is probably what you wanted to do - but changing root's shell is not the same thing.

You COULD disable root's shell IF you had a secondary "root" user (with user id and group id 0) and only used this secondary user as "root". But it's still unncessary - if you had this secondary user set up, you should just set the root user's password to a long random string of characters and leave the shell alone.

Paul

[RWF]

RWF, you really don't want to disable root's shell. That ability is disabled in NodeWorx because it is a bad idea. If this setting was enabled in NodeWorx I guarantee there would be an endless stream of users locking themselves out of their server and blaming us.

Disallowing root logins VIA SSH is probably what you wanted to do - but changing root's shell is not the same thing.

You COULD disable root's shell IF you had a secondary "root" user (with user id and group id 0) and only used this secondary user as "root". But it's still unncessary - if you had this secondary user set up, you should just set the root user's password to a long random string of characters and leave the shell alone.

Paul


Paul this feature request was actually more about allowing us administrators to change the root user "folder" or shell, just like one can change it for all the other users under NodeWorx | SiteWorx | Shell Users"

I need to be able to change the root user's shell.

[IWorx-Paul]

In NodeWorx under SiteWorx "Shell Users" one can change all the user's shells, EXCEPT root!

I need to be able to change the root user's shell.

Sorry RWF, I was responding to the initial message content, quoted above, which seems to be talking about shells, not folders. The message and title seemed to conflict so I was confused.

Anyway, we'll take this under advisement. This is the first I've heard of someone wanting to change root's home directory.

Paul

[RWF]

Besides I read all over the Internet that the allowing root login is a security risk and that it is not needed.

I have used "usermod" to change the root "folder" or shell to /bin/nologin, and now I can't "su -" to root when logging in as another user, something non-InterWorx users is able to do. It now gives me an an error:

su: /bin/nologin: No such file or directory

Which is why I posted my feature request of allowing me the change the root shell like I can with all the other user's I could fix this problem real easy.

I have now been told by IWorx-SocHeat that Sago needs to do an emergency boot, read US dollars, mount another partition, and fix /etc/passwd manually.

Sorry first of all I have 40 accounts/sites running full steam, secondly if this machine is not gonna work like other Linux setups, speaking about the above problem of usermod and not being able to su to root, plus I can't add an Apache module, I rather cut my ties now, buy another machine, without Interworx which is a shame because I do like your interface, learn the dreaded "Webmin" and port the sites over to that, then discontinue the first box.

[RWF]

Sorry RWF, I was responding to the initial message content, quoted above, which seems to be talking about shells, not folders. The message and title seemed to conflict so I was confused.

Anyway, we'll take this under advisement. This is the first I've heard of someone wanting to change root's home directory.

Paul

Your confused? Well I am even more confused :) This /bin/nologin sounds like a folder to me but maybe it's a shell, in a nutshell!

The request only came about because I was not able to "su -" to root, and now my root is screwed, after having used usermod -s /bin/nologin root, something that seems to be possible by non-Interworx users.

[IWorx-Socheat]

This is working like other Linux setups. Linux is doing exactly what you asked: disable the root user from logging in. I think you have a few things confused.

Setting the root user's "folder" is not the same thing as setting the root user's "shell". The root user's folder is "/root". The root user's "shell" (the command line interpreter) is typically set to "/bin/bash", which is an executable file not a directory. They are two entirely separate things, and changing one does not change the other.

Any user who wants shell access *must* have a valid "shell" set, and setting the shell to /sbin/nologin disables shell access for that user. This means disabled login access from the console, from ssh, even from using 'su' as a another user. Additionally, the correct command for disabling shell access is:
usermod -s /sbin/nologin <user>
not /bin/nologin. Neither command should be run on the root user.

Shell access is *not* the same as SSH access. SSH access is the ability to login to a box remotely over a secured connection. Shell access just means the user can login to the box. Allowing root *SSH* login can be a security risk, but not root login in general. You obviously need to be able to login as root under certain circumstances. Once you get your root access back, please see my previous post on how to edit the SSH config file to disable root SSH logins.

If there's something we could do to help, we would - but anything we would do would require us logging in as root - which unfortunately isn't possible with the shell set to "/bin/nologin". We can't even get in to change InterWorx code. I'm afraid your stuck between a rock and a hard place. :(

[RWF]

...We can't even get in to change InterWorx code. I'm afraid your stuck between a rock and a hard place. :(

Are you telling me that any future Interworx updates will now not work/be installed on my computer?

[IWorx-Paul]

I'm honestly not sure if the updates would apply with root's shell set to an invalid value or not, I've never tried. Regardless, we can't make an entire release to temporarily enable functionality in NodeWorx that may or may not work, just for this issue - building a takes a lot of time.

Having sago fix this shouldn't be a very big deal. The best thing to do is to schedule a maintenance window for them to fix the /etc/passwd file. I can't see it taking more than 15 minutes of downtime.

Paul

[RWF]

Well of course I understand you guys can't release something for just me, and anyways nothing in a rush.

One final question before I need to make a big decision.

Is adding an Apache module on a Linux box with Interworx different than say if the box were using CPanel, Webmin, Plesk, etc.?

[Justec]

I did the same thing and locked root from having shell access. Sago was able to fix it and what I was trying to do and now do is blocking SSH access for root. Which means logining in as another user and SU'n. I do it more complicated thant that just b/c I'm paranoid, but basically the same end result.

[RWF]

I am a little confused as to now in three different threads, no one from InterWorx has replied about Apache modules.

Obvisouly I am not a Linux expert, and my question may not be relevant, but I really find it frustrating that I now have to ask it the fourth time!

Is adding an Apache module on a Linux box with Interworx different than say if the box were using CPanel, Webmin, Plesk, etc.?

[IWorx-Socheat]

Are you still referring to your mod_bwshare module? If so, this is what I did to get it installed (as root)

yum install apr-devel
yum install apr-util-devel

Then, I was able to run the installation instructions, without any problems, from the site you provided:
http://www.topology.org/src/bwshare/README.html

under "Installation of bwshare as a DSO module for Apache 2"

I did not attempt to configure mod_bwshare. It worked for me, on a CentOS 4.2 box, so it definitely is possible, but your results may vary. However, I must say that this is not officially supported by InterWorx as this is configuring the system Apache, which is provided by the distribution and not by us.

[RWF]

Thank your VERY much IWorx-SocHeat for your much appreciated help regarding that module.

My a bit more specific question here however was, if installaing an Apache module on a Linux box using InterWorx is different from Linux boxes using other management systems.

Hope to get that one answered too, but thanks again for going out of you way regarding the mod_bwshare module!

[RWF]

BTW I think things went wrong because I mistakenly did "usermod -s /bin/nologin" instead of "usermod -s /sbin/nologin". Had I done that I could perhaps have used "su -" to switch to root.

One typo is all it took to mess it up :(

Another reason for adding features, in the future, for root user management, including disallowing direct logins, so Linux rookies like me won't mess up their boxes :)

[IWorx-Socheat]

My a bit more specific question here however was, if installaing an Apache module on a Linux box using InterWorx is different from Linux boxes using other management systems.

It's not any different than other Linux boxes. The general steps are the same. You're working with the system apache, which is installed by the distribution. Each distribution may have it's own preferred way of doing it, but installing InterWorx doesn't change the procedure. You will still need to somehow create the .so module which, depending on the module, may require compiling manually, running apxs, or other commands. Some modules are available in packages (Debian has a deb package for a variety of apache modules), but again, it will depend on your distribution.

BTW I think things went wrong because I mistakenly did "usermod -s /bin/nologin" instead of "usermod -s /sbin/nologin". Had I done that I could perhaps have used "su -" to switch to root.

I don't think that would've solved the problem, because setting the shell to /sbin/nologin disables shell access entirely. No attempt to get into the system as that user will work. You would most likely get this message:

This account is currently not available.

Another reason for adding features, in the future, for root user management, including disallowing direct logins, so Linux rookies like me won't mess up their boxes :)

Again, just so there's no confusion, what you're looking for here is disabling *SSH* root logins. Disallowing *direct* root logins is what you ended up discovering, and is obviously not ideal. :) You'll be happy to know that disabling SSH root logins is in the next release of InterWorx. :)

[Justec]

Im sure you know this arleady, but...

Im not sure how the other panels work, but Iworx was designed to allow you to modify apache without affecting Iworx itself. There is a totally different apache and mysql running for Iworx.

[RWF]

Again, just so there's no confusion, what you're looking for here is disabling *SSH* root logins. Disallowing *direct* root logins is what you ended up discovering, and is obviously not ideal. :) You'll be happy to know that disabling SSH root logins is in the next release of InterWorx. :)


Actually it is the other way around, I think :), I wanted to disallow DIRECT root login. Meaning that potential hackers could not use that username and "only" had to guess the password. I could then login using my totally unknown username and "su -" to root. That is what I wanted to do!

[IWorx-Socheat]

Actually it is the other way around, I think :), I wanted to disallow DIRECT root login. Meaning that potential hackers could not use that username and "only" had to guess the password. I could then login using my totally unknown username and "su -" to root. That is what I wanted to do!

You couldn't quite do exactly that. If you disable direct root login, no one would be able to switch to the root user, even if you knew the password. This has nothing to do with InterWorx, but is part of Linux.

What you'd want to do is either set up 'sudo' correctly for your 'unknown' user, so that you can still run root commands, just not as the root user. Then, set the root password to some gibberish, and only use 'sudo'

Or, you could do what Paul suggested earlier in this thread and create a secondary root user, and again set the main root password to gibberish.

[RWF]

This is really strange. Why is so many websites then writing that you can do that?

http://www.webhostgear.com/24.html
http://forums.fedoraforum.org/archive/index.php/t-47795.html
http://www.wbglinks.net/pages/openbsd/tipstricks.html
http://www.linuxquestions.org/questions/history/369867

[IWorx-Socheat]

I think this is just an issue with semantics. While the couple links you posted called it "direct root login", all four sites detail how to prevent logging in as root via SSH by editing the /etc/ssh/sshd_config file, and make no mention of using usermod. They call it "direct root login", I call it "SSH root login". :rolleyes:

When I think disabling "direct root login", I think disabling the root account entirely, which is what you did via usermod.

[Justec]

It’s really pretty simple stuff, but like Socheat said the semantics can make it confusing.

If you disable REMOTE root login that is disabling root from SSH'n (port 22) directly. All this does is keep script kiddies from gaining root access by doing a bunch of dictionary passwords with the username root. You would have to log in as any other user that had REMOTE (SSH) login capability. Then you would SU to root. The trick here is the script kiddie would not know this other non-root user login name, so it's like double (or triple) protection because they would have to guess the username as well as the password. Then they would have to do a su – and guess the root password.

If you disable the root shell access that means even if you are sitting in front of the linux box (not SSH, just keyboard and monitor) you would not be able to login as root. You would have to do some kind of backdoor thing to fix the /etc/passwd to add root back to a valid shell access. You really DO NOT want to do this.

Another thing you can do if you don’t offer SSH access to your clients (which you shouldn’t because its just not worth the hassle) is block port 22 all together in the firewall and only whitelist your IP address (you would need a static IP to do this of course). This way they can’t even try to login and also takes a little load of your server form the nightly hack attempts.

[RWF]

Are you still referring to your mod_bwshare module? If so, this is what I did to get it installed (as root)

yum install apr-devel
yum install apr-util-devel

Then, I was able to run the installation instructions, without any problems, from the site you provided:
http://www.topology.org/src/bwshare/README.html

under "Installation of bwshare as a DSO module for Apache 2"

I did not attempt to configure mod_bwshare. It worked for me, on a CentOS 4.2 box, so it definitely is possible, but your results may vary. However, I must say that this is not officially supported by InterWorx as this is configuring the system Apache, which is provided by the distribution and not by us.


Hmm SocHeat I know you went out of your way for this reply, but I am first now trying this and get stuck here:

apxs2 -c mod_bwshare.c

It then says:

-bash: apxs2: command not found


huh?

[IWorx-Socheat]

Try just 'apxs'.

[RWF]

Try just 'apxs'.

Yeah that worked, however Even after I restarted Apache it does not seem like the module is running.

I then read this on the the author's site:

"On my SuSE 9 systems, I don't need to modify the httpd.conf file, but when I run Apache 2.0.50 compiled from source, I have to add this line to the httpd.conf file:

LoadModule bwshare_module modules/mod_bwshare.so"

But when I add, in the bottom that line, with the right directory of course, in httpd.conf, Apache won't restart.

[RWF]

Ahh never mind I made a mistake, it's loaded now :)

[RWF]

Even though the intitial topic was to allow root change, it seems it turned into a bandwidth throttle thread.

Anyways for those of you interested in such, I can say that bwshare worked as it was supposed to, but I am afraid I have to turn the module off, as I am afraid that search engine spiders might get stuck with a "503" error, if they exceed set amount of bytes/second or files/second, and can't continue. I have suggested to the author that he allow an option so when exceeding criteria it will just delay further delivery, instead of showing a "503" page.

My problem was when somebody download a large zip or video file, at it would be delivered at 300KB/second. That would slow everybody else down quite a bit.

I solved my problem with a php delivery script such as below:

<?php
// First get file filename from URL
//

// Then deliver file
// Smaller files at full speed
if ($nFileSize < 100000)
readfile($sFilename);
else {
if ($file = fopen($sFilename, 'rb')) {
while(!feof($file) and (connection_status()==0)) {
print(fread($file, 1024*8));

// Simple time delay (nano seconds) to slow things down
// Of course this will slow down even slow connections!
usleep(300000);

// A fancier delay can fairly easy be made,
// by counting bytes delivered within a timeframe
// and then delay accordingly

flush();
}
fclose($file);
}
}
?>

So instead of having a link to say a large zip file on your webpage like this:

<a href="humongous-zipfile.zip">Humongous Zipfile</a>

It is now this:

<a href="/php-functions/deliver.php?humongous-zipfile.zip">Humongous Zipfile</a>