Permanently lift up default user "uucp" to "root" level

[MarioW]

Hello community,

I have a problem with a jail command I try to access as "uucp" user (because the actual command comes from the UPS service):

Execute jexec with user uucp / or how to execute jail commands from UPS service

Hello community, I just bought a UPS (APC Back-UPS CS 350) which seems to work very fine to shutdown my FreeNAS server. But: I want more ;) I want to shutdown other critical devices in my network automatically too. Unfortunately, the other devices are really heterogenous, so I couldn't use any...

www.ixsystems.com

I decided to also post this question here, because maybe it is more about user authentication than actual having an issue with the jail itself.

Summed up, the problem is: The command...
su -m uucp -c 'jexec ioc-MW-FreeBSD-Jail01 python3 /home/jailuser/shutdownUbuntuVM.py'
..results in jexec: jail_attach(1): Operation not permitted

Summed up: Is it possible to give the "uucp" user permanent "root"-like access level?
So far I weren't able to do so, it seems, that FreeNAS doesn't like that.

Am I missing something?
For details, please checkout the other thread I posted above.

Thanks very much in advance!

Best regards
Mario

 

[garm]

mods will probably complain about the double post

 

[MarioW]

Sorry for that.
I just thought, the question here is maybe more related to the actual user access level topic, than the actual jail topic.

I promise, I won't do it again.

 

[jgreco]

Hello community,

I have a problem with a jail command I try to access as "uucp" user (because the actual command comes from the UPS service):

Execute jexec with user uucp / or how to execute jail commands from UPS service

Hello community, I just bought a UPS (APC Back-UPS CS 350) which seems to work very fine to shutdown my FreeNAS server. But: I want more ;) I want to shutdown other critical devices in my network automatically too. Unfortunately, the other devices are really heterogenous, so I couldn't use any...

www.ixsystems.com

I decided to also post this question here, because maybe it is more about user authentication than actual having an issue with the jail itself.

Summed up, the problem is: The command...
su -m uucp -c 'jexec ioc-MW-FreeBSD-Jail01 python3 /home/jailuser/shutdownUbuntuVM.py'
..results in jexec: jail_attach(1): Operation not permitted

Summed up: Is it possible to give the "uucp" user permanent "root"-like access level?
So far I weren't able to do so, it seems, that FreeNAS doesn't like that.

Am I missing something?
For details, please checkout the other thread I posted above.

Thanks very much in advance!

Best regards
Mario

"uucp" is the UNIX-to-UNIX copy user. This probably isn't the right user to use.

 

[jgreco]

Summed up, the problem is: The command...
su -m uucp -c 'jexec ioc-MW-FreeBSD-Jail01 python3 /home/jailuser/shutdownUbuntuVM.py'
..results in jexec: jail_attach(1): Operation not permitted

Sorry, I apparently spazzed out there mid-post. I was trying to requote this bit.

Put simply, this is a dumb invocation. Getting "su" to work correctly even with a standard user in a scripting role is a little tricky, and uucp's shell is uucico.

If you read the manual for jexec, it *has* the capability to specify a username for execution within the jail, and I expect that something like

jexec -u uucp ioc-MW-FreeBSD-Jail01 python3 /home/jailuser/shutdownUbuntuVM.py

is more likely to work, as long as you are running as root.

 

[MarioW]

@jgreco thank you very much.

Put simply, this is a dumb invocation. Getting "su" to work correctly even with a standard user in a scripting role is a little tricky, and uucp's shell is uucico.

As stated in my linked thread in the first post, it seems, that I have no other choice, than using uucp.
My UPS service runs with this user, therefore I need to get the user to be able to execute the commands from jail.
I should have made more clear, why I made this invocation: I just used it to proof, that this command fails (due to the user), where the invocation succeeds, when performed as root.
So this command is only a "test".

I thought, if I will be able to execute this command successfully, after elevating the uupc user to root (how?) I can continue.

If you read the manual for jexec, it *has* the capability to specify a username for execution within the jail, and I expect that something like

jexec -u uucp ioc-MW-FreeBSD-Jail01 python3 /home/jailuser/shutdownUbuntuVM.py

You are definitely right, but I think, this is not my problem.

is more likely to work, as long as you are running as root.

That's the problem, it seems that I can't control that. uucp runs UPS service, which has to call the jail command (either via jexec or iocache exec).

That is why I asked in the first place, if there is any chance, to get this strange user uucp to have actual root rights. Even though, this seems to be very special..

 

[jgreco]

You are definitely right, but I think, this is not my problem.

Ok, so yeah, if you're not running as root, that'll be a problem. I'm basically debugging this without seeing this firsthand. I understand how the services we're discussing work, having ran two of the region's three UUCP hubs back in the day, and having run NUT for years, but the way this has been assembled is a little puzzling.

That's the problem, it seems that I can't control that. uucp runs UPS service, which has to call the jail command (either via jexec or iocache exec).
That is why I asked in the first place, if there is any chance, to get this strange user uucp to have actual root rights. Even though, this seems to be very special..

I think a major impediment is that whoever wrote this decided to repurpose the UUCP user, which was probably the expedient way to "make it work" for them, because by default FreeBSD ownership for cua* devices is uucp:dialer. But what *really* should have happened, and this might not be obvious to people who don't understand the history of UNIX dialout operations or aren't really familiar with the group permissions structure of UNIX, is that a new user should have been created for "ups" or "upsbot" or whatever, and then that user should have been assigned "dialer" as either the primary or a secondary group. Using group dialer gives you the same access to cua* devices but does so without the tragic complications of having uucp's uucico as a shell. Hope you see what I'm sayin'.

If this UPS stuff is something that is provided by FreeNAS, I would suggest filing a bug report that UPS processes should run as their own user ID, NOT uucp, and be group access to dialer. Feel free to link these posts. Developers or admins younger than maybe 40 will probably not have had exposure to UUCP and this isn't the first example of serial port confusion I've seen.

This still doesn't get you access to root. There are illicit ways to do that, but the real fix is to have a set-user-id wrapper in C, compiled, that can execute your script as root. The simplest version of this would be something like this as "mysuid.c":

Code:

#include <stdio.h>

int main()
{
     exit(system("/path/to/python /path/to/your/script"));
}

which is dangerously off the top of my head. You need a C compiler (do this in a jail or on a different FreeBSD host), and then "cc -o mysuid mysuid.c" to compile. This gives you a compiled result named "mysuid".

So you place that executable in the same place as your script, and then, very importantly, "chown root mysuid" and "chmod 4111 mysuid" which sets it up so that anyone on the box that runs "mysuid" will have the program elevated to root, and then "mysuid" will call "python /path/to/your/script" as root.

This is not guaranteed to work as there are potential complications, but it's my best shot at it when I don't have a lot of time to go into detail.

 

[MarioW]

@jgreco
Thank you very much!
I just created a new Jira issue for the long term solution and hope, the developers will catch that up.

https://jira.ixsystems.com/browse/NAS-103983

If you have any relevant information that I should add to this issue, feel free to either comment the ticket directly or give me a hint.


I don't understand the "dialer" part so far - indeed I haven't grown up with UNIX. Instead I grew up with MS DOS, Windows -then late change to Linux and decided to go with FreeNAS, even tough I knew, at some level I might have to dig deep into FreeBSD - and here we are
My profession is more µController embedded software development with small embedded operation systems.

The set-user-id wrapper looks good too, I'll plan that over Christmas holidays, since I never compiled in this environment - I probably need some time to try and error things out

I just wanted to be sure, that I didn't miss anything - maybe there is an easy solution, that I just didn't see - but now, with your comments - I feel confirmed, that I really hit the border regarding, what is typically possible with FreeNAS in it's current setup.

Maybe I am really the first one, trying to do more complex stuff with the "Shutdown command" parameter of the UPS service.

 

[jgreco]

While waiting for some laggards in 18 parallel system builds to complete...

UUCP is "UNIX-to-UNIX copy", which is a system that allows UNIX systems to automatically dial out and log into another UNIX system and enables it to copy files, or, more importantly, execute commands. In the era before the Internet, this is how individual nodes or local networks would communicate with other - via modem, over the telephony network.

Your local host or network would have a host on it with one or more modems. These could be used as dial-out, dial-in, or bidirectional. A dial-in line would answer with a "login:" prompt and wait for a username and password. Similar to the way you could have a directly connected terminal such as a VT100, you could insert a pair of modems, one at the host, one by the terminal, to allow a VT100 to communicate over the phone line and call the modem on the host, get presented with a login:, and go about your business. Your UNIX host could also allow a shell user to dial out, using "cu", "tip", or "kermit", but because this allowed a user unrestricted access to a phone line, these /dev/ devices were typically limited to a restricted group - "dialer" being a reasonable example - so that only users who were members of this group (and presumably trusted) could dial out.

But the clever bit was that you could have one UNIX host call another and run a command, copying data along the way. This was the UUCP system. When your local host wanted to send mail from yourbox!mariow to solaria!jgreco, your local MTA would accept the message, queue the mail for UUCP from yourbox to solaria, and then yourbox would call solaria, possibly hours later when the rates were cheaper, or when some threshold of traffic had been reached, and would run "rmail solaria!jgreco" and pass the message over the serial link. It was actually much more complicated than this because most nodes did not directly dial each other, but rather routed traffic over intermediate nodes.

I'm trying to pack a LOT of stuff into a hopefully understandable short description of some REALLY interesting stuff. You don't need to know or fully understand it. But if you understand that "dialer" controls who can create connections out of the serial port, hopefully when you do an "ls -l /dev/cuau0" and see that it is owned by "uucp" user and "dialer" group, you will understand the context of my answer somewhat better.