dealing with root user

I have a question about the changes to root.  I have used the root user to copy some files to my array in the past.  Because of that I can only access those files while logged in as root.  How will the changes made to the root user affect my access to those files?  thx!

Run the New Permissions utility.

I have a question about the changes to root.  I have used the root user to copy some files to my array in the past.  Because of that I can only access those files while logged in as root.  How will the changes made to the root user affect my access to those files?  thx!

You can no longer log in as root via SMB (or AFP - but for AFP it's always been like that).  The ability to do so is a bug in 5.0 which has been there since the beginning but I never saw because I normally don't log in as root.  If you have files lingering around with owner set as root, see BRiT's post.

This also applies to any actions you take while logged in via, e.g., telnet.  If you have to make changes to files mounted at /mnt/disk* or /mnt/user/*, then you should do so using 'su nobody' or 'sudo nobody ...' first.  (You could use any user you created instead of 'nobody' if you want as well.)

I had noticed this almost instantly on RC4. I guess my MAC has been using root all along (via SMB) and I had forgotten (even though I had created an account for the mac).

I just remapped the SMB share with the mac service account. ran new permissions script..

Works like a champ.

I had noticed this almost instantly on RC4. I guess my MAC has been using root all along (via SMB) and I had forgotten (even though I had created an account for the mac).

 

I just remapped the SMB share with the mac service account. ran new permissions script..

 

Works like a champ.

Yes, there are probably going to be a lot of people having this issue because of cached credentials - which is why I moved the post here.

Thanks for pointing me in the right direction.  I am running the script now.

I have a question about the changes to root.  I have used the root user to copy some files to my array in the past.  Because of that I can only access those files while logged in as root.  How will the changes made to the root user affect my access to those files?  thx!

 

You can no longer log in as root via SMB (or AFP - but for AFP it's always been like that).  The ability to do so is a bug in 5.0 which has been there since the beginning but I never saw because I normally don't log in as root.  If you have files lingering around with owner set as root, see BRiT's post.

 

This also applies to any actions you take while logged in via, e.g., telnet.  If you have to make changes to files mounted at /mnt/disk* or /mnt/user/*, then you should do so using 'su nobody' or 'sudo nobody ...' first.  (You could use any user you created instead of 'nobody' if you want as well.)

"su nobody" does not work because nobody has no shell. We could use an "allow telnet" checkbox as a per user setting so users can make an "admin" user that can telnet and uncheck the box next to root to prohibit. root should always have a shell set but but other users only need one if the box is checked.

I have a question about the changes to root.  I have used the root user to copy some files to my array in the past.  Because of that I can only access those files while logged in as root.  How will the changes made to the root user affect my access to those files?  thx!

 

You can no longer log in as root via SMB (or AFP - but for AFP it's always been like that).  The ability to do so is a bug in 5.0 which has been there since the beginning but I never saw because I normally don't log in as root.  If you have files lingering around with owner set as root, see BRiT's post.

 

This also applies to any actions you take while logged in via, e.g., telnet.  If you have to make changes to files mounted at /mnt/disk* or /mnt/user/*, then you should do so using 'su nobody' or 'sudo nobody ...' first.  (You could use any user you created instead of 'nobody' if you want as well.)

 

"su nobody" does not work because nobody has no shell. We could use an "allow telnet" checkbox as a per user setting so users can make an "admin" user that can telnet and uncheck the box next to root to prohibit. root should always have a shell set but but other users only need one if the box is checked.

Good news and bad news... the 'nobody' user's shell is now set to '/bin/bash', but for some reason, the file '/etc/nologin' is not in the -rc4 release, so I will have to produce a -rc5.  So right now you can log in as user 'nobody' and no password is required - this is probably a slight security vulnerability.

Edit: that is incorrect - I was working with a test server where I had manually set the shell for 'nobody' to /bin/bash.  In the actual release, this is not the case.

+1 for a "allow telnet" feature. I would MUCH rather log in to telnet as another user, root makes me feel too dangerous.

+1 for a "allow telnet" feature. I would MUCH rather log in to telnet as another user, root makes me feel too dangerous.

Agreed, plus I think it would "future proof" it a bit for new users, as they can log in as whatever user they please, rather than learning about how to su to another user.

Just to pile on, and assuming I'm following this right, wouldn't it also be beneficial to disallow remote root for security reasons.  Perhaps make it optional, but disabled by default.  Could be a check box for the root users just like as discussed for "nobody"

Is there ever really a time someone might be able to remote in but unable to to use the local console?  other than headless / misbehaving video cards (like my own wake from s3 no-video issue)?

Is there ever really a time someone might be able to remote in but unable to to use the local console? 

Yes... all the time.

really?  like?  I'm really just curious. 

And I'm talking about remoting in as root vice remoting in as another user with admin privs.  Seems like if you really need to login as root, that is when you can head over to the console.  I am of course also assuming you are physically collocated.  If not then that is why it is an option and not hard-coded ;-)

1.  I log in as root.... always.  It teaches me to be careful.  I do not create additional users with root privileges as that is a different can of worms.

2. The servers are 3 floors away.  I don't even go in there except on rare occasions.

3. My servers are all headless since the LCD rack monitor tray died.  It is a PITA to move the standalone monitor in there and troubleshoot.

If a server faces the Internet, then I disable remote root login and work through a Dameware console.... My unRAID boxes do not face the Internet.

[nodding] a fair statement indeed.  I guess I'd still like to see it as an option, but I now have a better appreciation for other use cases.

At the risk of going slightly OT, though it is related, what are your reasons for not wanting other users with admin privs?  I thought (and I only stayed in the Holiday Inn Express for one night) that was considered a best practice vice using the actual root or admin accounts?

what are your reasons for not wanting other users with admin privs?

For one, people can be looser with their OWN password then they are with root pw.  Some lazy schmuck will used cached credentials, autologins, etc and get compromised.  It is safer to make those boneheads login as a user, and su root when needed.

oh ah well see now I'm not talking about "other users" ... I'm talking about you and me as the admins of the machine.  Heck if I had a user in my house who wanted access they woulnd't have admin access regardless; neither su nor as part of their user profile.

Heck one of my "deals" with anyone who asks me for what I call "friends and family computer level support" is that 1) they run as user only and not admin (i.e. typical win7 clients) and 2) after the first PEBCAK incident I don't allow them admin access without calling me.  If they don't like my terms, they are welcome to call someone else when they need tech support.

So for the actual admin, I still thought not using the default root / admin accounts for actual admin duties is considered a best practice.  For all other users, who shouldn't even have admin access, I woulnd't even give them the root password to use with "su"  And if I DID want to give someone else admin privs, then it would still be with a different user name than root or admin.

So for the actual admin, I still thought not using the default root / admin accounts for actual admin duties is considered a best practice.  For all other users, who shouldn't even have admin access, I woulnd't even give them the root password to use with "su"  And if I DID want to give someone else admin privs, then it would still be with a different user name than root or admin.

If I am giving them root privileges, I want them to su to "root" as it reinforces the "be careful numbnuts" aspect of the task.  If their general login has root privilages, then they will fubar something... guaranteed.  I the systems set up so I would get e-mail notification when ever su was used or root logged in.

In some cases, I do create an admin account, that is root equivalent, blocked from remote login (to prevent numbnuts from caching it), and tell them to su to that account.

Back in the day, I would create an admin pair for those users... bubba, and bubba_admin.... bubba_admin was blocked from remote logins.

 

If I am giving them root privileges, I want them to su to "root" as it reinforces the "be careful numbnuts" aspect of the task.  If their general login has root privilages, then they will fubar something... guaranteed.  I the systems set up so I would get e-mail notification when ever su was used or root logged in.

I agree not giving their general login root privs. 

But for allowing them access to root privs, if I had to, I'd do what my work does ... which is just what you say below, "admin pairs".  The benefits of course being: [username]-admin can be revoked (root cannot), passwords can be changed without needing to notify others (the only way to "revoke" root), logged and auditted, email notifications (as you mentioned), and offers non-repudiation (they can't deny they screwed something up). 

ALIBI: I am not an admin at my place of work, but I know that is how they operate because I see them do it and talk shop with them. 

In some cases, I do create an admin account, that is root equivalent, blocked from remote login (to prevent numbnuts from caching it), and tell them to su to that account.

 

Back in the day, I would create an admin pair for those users... bubba, and bubba_admin.... bubba_admin was blocked from remote logins.

So why don't you do this now? 

You have to realize that an unRaid server is conceptually different than a general purpose multi-user server.

The idea with unRaid is there are no local users and no local user home directories.  The only reason users are created via the webGui is for the purpose of authentication via the network protocol services.  If all your shares are Public, you don't have to create any local users at all.

So really the only person who should ever 'log into' an unRaid server is the "administrator" of the server, and that person needs root access, hence 'root'.  Also, if you think about it, other than messing with data on the array, there really isn't anything you can do on the server that isn't reversible because the root file system is entirely in ram and can be restored by a reboot.

The reason we need to use "sudo -u nobody" for local applications and/or plugins is because generally they are run as 'root'; and if those applications need to write files on the array then we have to make sure ownership of those files is something other than root so they are visible via the network protocols - or alternately, they could be left with root ownership specifically so they are not accessible via network protocols.  Make sense?

Sure does.  I guess the path I started the conversation down was perhaps more than "just a little OT" ... especially since no one has my root password or any admin privs my server and likely never will

For security reason Telnet should be disabled by default and install OpenSSH

For security reason Telnet should be disabled by default and install OpenSSH

It has been requested, several times. It would be nice that the package already come with unRaid for the greater good.

Except that would break a TON of forum posts with help and documentation that refers to telnet.  Joe user doesn't have a robust client like putty or know how to change port numbers.

I have a question about the changes to root.  I have used the root user to copy some files to my array in the past.  Because of that I can only access those files while logged in as root.  How will the changes made to the root user affect my access to those files?  thx!

 

You can no longer log in as root via SMB (or AFP - but for AFP it's always been like that).  The ability to do so is a bug in 5.0 which has been there since the beginning but I never saw because I normally don't log in as root.  If you have files lingering around with owner set as root, see BRiT's post.

 

This also applies to any actions you take while logged in via, e.g., telnet.  If you have to make changes to files mounted at /mnt/disk* or /mnt/user/*, then you should do so using 'su nobody' or 'sudo nobody ...' first.  (You could use any user you created instead of 'nobody' if you want as well.)

 

"su nobody" does not work because nobody has no shell. We could use an "allow telnet" checkbox as a per user setting so users can make an "admin" user that can telnet and uncheck the box next to root to prohibit. root should always have a shell set but but other users only need one if the box is checked.

just had a little talk with someone in another thread about using other users in Telnet sessions and the command he gave me was

su - %username% --shell=usr/bin/bash

You appear to specify a shell, so that should work...yes?

and, is this the correct way to do it?