User: Password:
|
|
Subscribe / Log in / New account

usermod as non-root user

usermod as non-root user

Posted Dec 11, 2008 3:09 UTC (Thu) by wtogami (subscriber, #32325)
Parent article: Fedora and CAPP

When is usermod ever useful to run as a non-root user?


(Log in to post comments)

usermod as non-root user

Posted Dec 11, 2008 3:18 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

I was wondering the same... I believe that the second paragraph answers this—Callum Lerwick was running it (presumably without any arguments) to get a quick reference on how to use it. Which I do occasionally for unfamiliar shell commands when I don't want to wade through a man page (or if a man page doesn't exist).

usermod as non-root user

Posted Dec 11, 2008 3:45 UTC (Thu) by wtogami (subscriber, #32325) [Link]

OK, then why would it be important to allow?

Presumably if the goal is only to learn how to use it, you could read the man page instead, which by certification requirements must be documented and complete or it is a bug that should be filed and fixed.

usermod as non-root user

Posted Dec 11, 2008 6:42 UTC (Thu) by dlang (subscriber, #313) [Link]

it could also be argued that running the command as a non-root user (especially with no parameters) is not really an attempt to change anything and so doesn't need to be audited.

_many_ *nix tools can be used by both privileged and non-privileged users. the non-privileged users can do the read functionality of the command, but write commands will fail.

usermod as non-root user

Posted Dec 11, 2008 13:13 UTC (Thu) by epa (subscriber, #39769) [Link]

In order to satisfy the religious edicts from CAPP, the tool could be split into usermod-real, which is the real usermod program, and usermod, which is just a shell script wrapper. The script would understand --help and --version but not much else, and would not invoke usermod-real unless running as root. That would comply with the letter and spirit of the law while not breaking the existing interface.

usermod as non-root user

Posted Dec 11, 2008 15:59 UTC (Thu) by felixfix (subscriber, #242) [Link]

If you will pardon a socio-politico comment :-) this is a common thing. Ban the tool when the tool itself is harmless, rather than the subset of its actions which are the real evil. I am especially familiar with this since I live in California and like to shoot guns, but it applies to all manner of things. It is a quite common human failing. I sometimes wonder of all the OSHA labels we get in the USA (do not step on the top steps or the backside of a ladder, do not use electrical devices in the bath) are a misguided attempt to get around that, but that's about when I decide that politicians are evil and my brain switches to a less annoying topic.

It's easier to ban dangerous products than ignorant people

Posted Dec 11, 2008 19:57 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Ban the tool when the tool itself is harmless, rather than the subset of its actions which are the real evil.

It's always easier (and more politically "correct") to ban dangerous products/tools rather than ignorant and/or unintelligent people. Notice that I don't mention evil/malicious people, as we (supposedly) have a law enforcement and criminal justice infrastructure to deal with them.

While there's some cynicism in my comment, I generally agree with you—There's a lot of regulatory compliance (e.g., the OSHA labels) forced upon consumer products—some might argue too much—because the consumer public simply has too much to think about at any given moment to fully understand the consequences of (mis-)using things. Like a simple usermod(8) shell command.

usermod as non-root user

Posted Dec 11, 2008 16:24 UTC (Thu) by zuki (subscriber, #41808) [Link]

A more useful scenario: rpm.

Running rpm -i as a normal user checks the dependencies and then either bails out or fails because it cannot lock the database. So when installing an rpm, you can download it, test for deps, download them, test, ..., and then do sudo rpm -i ... when ready.

Removing this rpm functionality would be a much bigger PITA.

usermod as non-root user

Posted Dec 11, 2008 17:37 UTC (Thu) by wtogami (subscriber, #32325) [Link]

I do agree that this in particular would be stupid. Did anyone suggest that this happen? It didn't at this point.

usermod as non-root user

Posted Dec 12, 2008 9:30 UTC (Fri) by zuki (subscriber, #41808) [Link]

Yeah, no one did yet. But the principle is the same - an unprivileged user calls a binary that can modify the system in a very important way.

usermod as non-root user

Posted Dec 11, 2008 18:10 UTC (Thu) by iabervon (subscriber, #722) [Link]

I often want to run important system-administration operations without the capabilities needed to affect anything in order to verify that my command line is correct before getting the capabilities.

Say you're trying to add yourself to a group for managing a new piece of software. How do you make sure you don't remove yourself from "wheel" accidentally, leaving yourself unable to apply critical security patches in a timely fashion? In order to be safe, you should be able to run the command in a "pretend" mode that will report the actions it would take without actually taking them (it doesn't seem to have it, so the rest of this is kind of theoretical). But if you're worried about making a mistake in running the command, you should be worried about making a mistake invoking "pretend" mode; to be safe, you should run it without the capabilities to cause actual changes, verify that the effects are what you want, and then acquire the capabilities to do it for real and run the same command.

As a policy, prohibiting attempting operations without appropriate permissions just increases the chance of security breaches due to administrator error.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds