Andreas wrote:
On Tue, Aug 18, 2009 at 8:14 PM, Andreas
wrote: Hi,
I'd like to calculate a command-string as root and pass it with su - -c into the context of a unprivileged user to run the command not as root.
Is this possible?
Shouldn't
su - <user> -c <command>
do what you need?
At least su - <user> -c whoami
prints <user> Here a rather daft example of what I like to do. Basically I need to know $d after the daemonuser created and filled
Mark Goldstein schrieb: the file to further process it as root.
== ./x ====================== #!/bin/bash d=`date +%y%m%d-%H%M` f=/mnt/sdb4/test/file_$d c='la ~ > '$f echo $c su - daemonuser -c $c =============================
myserver:/mnt/sdb4 # ./x la ~ > /mnt/sdb4/test/file_090818-1940 ~: la: command not found
Obviously I have to provide some envolope when passing $c to su.
Yes but more than that, you are specifying a command that doesn't exist. "la" is just an alias that apparently isn't getting read from bashrc in the child shell spawned by su. Even if it were, I still wouldn't rely on that. Nor would I rely on "~" resolving to daemonusers's home directory in a situation like this. That probably does work usually, I just have seen instances where it doesn't always. Things like the ~ and the la alias are really only there for interactive user convenience and should not be relied on in every conceivable unusual context like this and generally not for programming or script writing. Also, what is the goal here really? Since you aren't going into any subdirectories, a listing done as daemonuser doesn't look any different than the same listing done as root. There could possibly be a difference if root owned one or more subdirectories and had marked then as not executable by anyone, then if root did a ls -lR it would generate different output than if daemonuser did it. But you are only doing "ls -la" Even if some files are unreadable by daemonuser, all the directory entries are readable and so the ls output will be the same. Is it just a way of not having to guess or assume where daemonusers home actually is? That's a valid approach but myself I would probably awk it out of passwd directly. I won't claim it's a better approach, but I do know below works. On the other hand, su will fail if the user in question has been disabled or their login shell set to /bin/false. Maybe that was an intentional part of the reason for using it? Does the file being created on the usb drive need to be owned by daemonuser? If none of these are actually concerns then all you need is: #!/bin/bash d=`date +%y%m%d-%H%M` f=/mnt/sdb4/test/file_$d p=`awk -F: '($1=="daemonuser"){print $6}' /etc/passwd` cd $p ls -la > $f This also works, uses su, but the ">$f" is outside of the su child environment and so the file will be created owned by root by default. (could be chowned afterwards of course) Also notice the the "-" (aka -l, aka --login) is not necessary in the su args for this task. It's shorter and simpler than above, and about equally efficient, so I guess that makes it actually better than above, merely it took a few trial & error tries to get the su command right, vs above was actually more straightforward and required less testing for me. #!/bin/bash d=`date +%y%m%d-%H%M` f=/mnt/sdb4/test/file_$d su daemonuser -c "ls -la ~" >$f This also works which more closely matches what you were first trying to do, in that now daemonuser creates the output file, not the runner of the script: #!/bin/bash d=`date +%y%m%d-%H%M` f=/mnt/sdb4/test/file_$d su daemonuser -c "ls -la ~ >$f" Lastly, of course it was that $c variable that causes the difficulty so if you really need that debug display of the command before running it, you need to do a bit of caretaking. You have to prevent the ~ from being expanded until after it's in the child shell, yet you want that $f to be expanded now, because it won't exist in the child shell, and of course you need to quote or escape all the spaces... All of that is why I would use any of the 3 examples above and and not even bother trying to get all that right unless I really needed _exactly_ that behavior for some reason. But you were very close the way you used single-quotes to construct $c yet didn't include $f in them. That was half of it and you even spake the other half yourself when you said, essentuially, that you need to quote $c. That was exactly it in a nutshell. Note the echo isn't really going to be a fully valuable diagnostic. it will show $f, but the "~"working directory will just be "~" in that echo. Also, it's not actually necessary to do anything special to escape the ~ in this case, as long as it's included within a quoted string, even plain double-quotes, until it's ready to be used, so, Either of these works equally well, the only difference is the c=... line But the second way is a bit easier to read and maintain, make future adjustments etc. But it's just nit-picking. #!/bin/bash d=`date +%y%m%d-%H%M` f=/mnt/sdb4/test/file_$d c='ls -la ~ >'$f echo "$c" su daemonuser -c "$c" #!/bin/bash d=`date +%y%m%d-%H%M` f=/mnt/sdb4/test/file_$d c="ls -la ~ >$f" echo "$c" su daemonuser -c "$c" All these examples actually work. I would use the very first way that reads the home dir out of passwd instead of using any of the su ways. It looks more complicated but I think it's actually the lightest weight and least error-prone, but not but much of a margin so not that big of a deal. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org