If you run any command and it needs a certain username/passwd, how can you pass it into the command, other than using sudo? Can you write a setuid script from a shell script for various other users and then use that, or is that a stupid idea?
I know some commands have that built in like smbclient, but is there anyway that works for all of them, not just the ones that have that built in?
You should _NEVER_ have a SUID bit on a file unless you absolutely need it ... (eg. the passwd command needs it); if there is a bug that is exploitable (buffer overflow for instance), you risk the chance of a compromised in(?)security system.
As for your other question:
I'd say if you can't do it with unix pipes, then it probably depends on the command/program you're using. And I'd advise against it anyway.
lots of commands (eg ssh) have a -l option (or equivalent) to pass the login, but no password option (and if it did have it I'd advise against it).
If you don't take precautions, it's very possible it could be intercepted (.bash_history or any other numerous ways, some examples below).
Another example:
If this is on a machine others are on... think of the 'w' command or 'ps' command or 'top' command ...
Or what happens if (hypothetically speaking) you have a trojan horse installed ... (maybe it logs to a different file everything you type...)
And other examples I'm sure.
But to recap:
- Don't go the suid route for something like this ... bad idea
- Be careful if you're providing passwords on the command line.
- the commands/programs don't provide that option for a reason; but if you must you can try unix pipes or so (or some programs allow you to not require passwords).
Hope that helps
Whoa, didn't know it was so dangerous. Could you perhaps elaborate on doing it with pipes, I only ask from pure curiosity of the syntax. For instance, connecting to a smb server with smbclient goes like this:
smbclient //ss1/Win_Apps -U bmj465
then it asks for a password. Are you saying pipes can be used everytime in a consistent manner, or every command does it differently? Either way, how would you do it with smbclient?
And also, just out of curiosity, how would I go about the SUID route? I'm not quite sure how to set the SUID bit. Or, would it even work in this instance?
Sorry for all the questions, I'm just trying to learn...
Firstly, Don't worry about asking too many questions.
Suid bits can be set on the file with the 'chmod' command (man chmod for more info). I refer you to the man page because you can do it in more than one 'way' (octal mode and alpha mode).
Whether it'd work or not.. I don't know.. what are you trying to accomplish ? You could of course configure certain programs/protocols to not require a password at all (not recommended of course).
Unix pipes are an interesting subject. They connect the standard output of one command to the standard input of another command.
An example would be..
ls -alR / | less
which would do a recursive, long listing of every file in the / directory (assuming you have exec and read access on the directories). But, then it'd send it to less, so that you can view it one page at a time.
That's a simple example.
As for passwords.. I'm not sure it would work. I just meant if it were to work, it'd have to be something a bit more advanced.
I think it won't work because it's not immediately needed, and the pipe already does its work (hopefully that makes sense).
It may be possible, but I can't think of a way right now. I'd suggest you look up unix pipes (and related things such as redirection of data etc) for more info.
I don't know if I answered all your questions, because I'm really quite tired. If I didn't though, just mention it and I'll try my best to answer when I'm more alive.
I guess I wasn't very clear at all, sorry. I know all about chmod (OCTAL MODE ALL THE WAY!!), what I really wanted to know is if you could build something like sudo, (where it lets a normal user run a command as if they were the root user) except in my version it would let you run a command as some other user. I thought this might be possible by fiddlin' with SUID bits and whatnot, but maybe I'm barking up the wrong tree...
I think I understand why it probably wouldn't work with pipes. You're saying that all the info passes at once, before whatever you're accessing has the chance to ask for a password, right?
btw, I could alternatively su to the other users profile, but that would just add further username/PW troubles...
Well, take this for example:
metgod@deranged ~ $ ssh metgod@localhost | echo test
test
Password:
(of course that's just a simple example that may or may not be the best -- point is that the output of the first command is connected to input of the second stream, _but_ you can do all sorts of stuff depending on which commands you're using).
That being noted, you can configure certain programs to not require a password. Just use caution with that of course (i'd have to look it up as I don't remember it off hand).
About suid.. I don't think it's what you're after ... at least not entirely. The problem is, how is the program (if it's not root) supposed to change it's permissions ? Take for instance a system that has 2+ users (other than the normal system accounts).
We'll call them 'user1' (id 1000) and 'user2' (id 1001).
Let's say that user1 writes a program that will try to change the program/process to a specified uid/euid.
Now they try to run it with a passed arg... '1001'.
It fails because it doesn't have the right permissions (unless the person running it is actually root/uid 0).
If you remove the suid bit on 'su' for example, then you will basically break the command ... But this very fact is why you should be careful to not have suid files that you absolutely don't need.
Are there ways around this all ? I'm pretty sure there are, but I'm not sure of them all.
if you have any more questions, feel free to ask and I'll try to answer (and hopefully these are satisfactory enough answers).
As another example, consider the below code (just wrote it real quickly so forgive the ugliness):
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
int main(int argc, char **argv)
{
if (argc != 2)
{
fprintf(stderr, "Usage: %s <uid>\n", argv[0]);
return 1;
}
printf("Attempting to change to uid specified ...");
if (setuid(atoi(argv[1])) < 0)
printf("Failed ... uid is still %d\n", getuid());
else printf("Success!\n");
return 0;
}
If you try to run this as a normal user, and you specify an id other than yours, you'll see it fails.
But if you make it suid AND change the owner to root, then you can specify any id that is valid and it'll succeed.
If you make it suid and do NOT change the owner, then you'll see any id other than yours will fail.
EDIT:
I'm sure you can (now if not before) see why it's dangerous to have suid files lying around. If any contain an exploitable bug, then you risk the chance of shell code being injected (for example), thus a root shell very likely being created.
I do see the dangers in having suid files lying around, but all that aside (I'm more interested in the "theory" behind it) I don't know if you quite understood my question... I'll start from the beginning and provide as much info as I can:
Problem: I want to connect to many different remote smb/cifs servers, but I want to be able to just run a script to do it instead of opening up the terminal and entering many different smbclient command requests. Thusly, I would like to find a way (it can be ugly since I'll never see it again) to connect to them, passing my username and password to them so I can run the script and be connected to all of them.
Solutions: My first theoretical approach was to create something similar to the "sudo" command (or use the sudo command) to run the smbclient command as the user that has full access to the smb servers (who is different than me), therefore eliminating need of entering a username or password. In sudo, the command just checks /etc/sudoers for a list of users that have permission to use it. I was wondering if you could make a similar list for another users permissions, eg. instead of root privileges, you would have a different users privileges.
The second theoretical approach (you came up with) was to pipe the password into the smbclient command somehow, etc., etc.
I'm sorry if I'm being difficult, I suppose I didn't know how to pose the question I was after an answer to. ;D
btw, the real smbclient syntax would be:
smbclient \/\/ss1\/Win_Apps -U bmj465
(You have to escape the /'s)
Sudo:
http://www.gentoo.org/doc/en/sudo-guide.xml
That's a nice overview of the sudo program. You might want to check out the man pages to sudoers and sudo of course (and maybe the website of the sudo program itself).
I'm unfortunately (for you) very ignorant when it comes to samba. Personally, if I had to get access to those drives, I'd either mount them (if in same machine and kernel config allows it) or just login to the machine (different machine) physically. But honestly maybe samba has other benefits (really don't know since I have no need for it).
Let me know if you need any more help. Hopefully the sudo article will be of a good help to get what you're after (since you said it might be a solution...).
It's on a different machine, so I can't just mount them, and the servers are configed to kick you off after a certain period (also when you shut down the computer). Anyway, thanks for the info, I learned alot more from all the stuff you said then I thought I'd learn, whew. I looked over that sudo link you gave me, turns out it's alot more complicated than I initially thought so I'll probably try and figure out the pipe method.
Thx again, you're a great help! ;D
Well, it might be worth it to learn sudo. There was really only one part of it though, that matters (if you've already configured sudo). It's simply adding a line to say which users can run this stuff as.
I would be curious to see your solution if you don't go that way. I don't know how samba works, so can't really offer much help there I'm afraid.
Glad I could be of help otherwise, though!
Let me know how it goes or if you have any other thoughts/concerns/questions.
Oh yeah, I didn't mean I wasn't going to learn bout sudo. I try to learn everything about everything I possibly can. Sudo's neat and powerful and all, but I was looking for something less involved than that. Though, the way my research is going, I'd say using pipes is going to be pretty ugly...(if not impossible)
Yup.. I don't think it is in this case (which I think I said above somewhere). But just meant if it is possible it may be that way. But if is the keyword.
I'll see if I can come up with any other ways though. will let you know if I come up with anything.
Okay, so here's my "pipe theory." Firstly, pipes send info immediately, so just piping in the password straight to smbclient doesn't work. So here's how my theory works, a roundabout way:
benthehutt@mayonnaise ~ $ smclient \/\/ss1\/Win_Apps -U bmj465 | someCommand password &
OR
benthehutt@mayonnaise ~ $ smclient \/\/ss1\/Win_Apps -U bmj465 | sudo someCommand password &
#Where sudo is later used in order to delete this entry from bash.history and other such places
Note that the someCommand I am referring to doesn't exist (at least not to my knowledge) so I'll probably just end up writing one. Here are the basic things it needs, I think (feel free to jump in anytime with hints or ideas, you know this alot better than me):
1. someCommand uses either wait or sleep to check on smbclient. Sleep would be used with a loop in order to check on the process every few seconds, wait would be used if the PID returns something when the password prompt comes up. (I say both ways cause I don't know if wait will notice when the smbclient password prompt comes up, or if there is anyway to tell when it comes up with sleep)
2. someCommand then passes the password to smbclient. (It would be stored in $1, right?)
3. someCommand would then delete necessary entries from bash.history, etc.
4. someCommand exits and the smb server is connected
That's my theory anyway. I haven't really looked into security issues, I think I'll look into the way passwd keeps stuff safe and try to emulate it. Though, I don't really care about the security, so I'll probably put it off so long it never gets done (just being honest). Please tell me any flaws or jumps in logic you see, you know alot more than me about this.
Thx ;D
Kind of a bit busier today, but here goes a hopefully useful/coherent reply:
Firstly, if you use a bash script for this command, then yes, the first argument after the command name would be in '$1'.
If I were to write a program for this, I'd probably try to use C (because then you have certain system calls at your disposal, among other things).
For how passwd does things, check in to the crypt (3) function ('man 3 crypt'). Also might want to check login(1) and passwd(1). Basically, the system takes what you supply as the password, encrypts it with the same algorithm and salt (etc) and then compares it to the entry in the real encrypted password file (the shadow file in these days). But all of that might not even be important for what you're after.
Now for your task:
I can't think of a way off the top of my head (that I know will work 100%). But here are some ideas to play with.
- Extend samba to allow you to pass the password (I don't have any idea how samba is coded but I'd imagine this is possible somehow). I don't see why this wouldn't work...
- I had played with an idea of using the pipe (or popen since I'm lazy ;D ) system calls, but unfortunately that won't work nicely I think. But see below about IPC in general.
In addition:
I'm not sure the command you had thought out would work in the way you suggested. The reason is the way pipes work. That being said, if this is possible (without sudo), you will need to have the two programs communicate with each other (via IPC etc [pipes being one of the forms of ipc]).
Admittedly, IPC isn't my strong point, but it's something I've studied briefly and am hoping to study it more very soon (actually quite a few things).
Samba is open source, right ? I think of the things I mentioned, the most efficient way would be to extend samba. Basically something like this (haven't thought this out in full though):
You pass the client a password via an option, and set a flag saying the password is already specified. Then, when the program would normally prompt the user.. if the certain flag is set, then you just use that string (the password) instead. AFter it's done, clear the password (which you allocated when the password is passed in).
I'm kind of distracted, so better post this so you at least have some more ideas. I should be able to reply some time later today. So if you have anything else thought out, I can reply then.
Hopefully I can have more time then too and help more.
Decided to do a bit of research .... So, you might want to take a look at these:
http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html#id2570000
Particularly this part:
set to NULL user passwords
I think that might be of help (that or I read it wrong).
Also:
http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html#id2571979
And even better:
Quote
Or both the username and password can be supplied by using the -U option, including the username and password separated by a percent (%) character:
$ smbclient //maya/e -U kelly%kellyspassword
More of which can be found here:
http://us4.samba.org/samba/docs/using_samba/ch05.html
Does this help ? :)
HA! Metty you're a genius!! Or at least a man that researches things he does thoroughly! Anyway, thanks for this stuff, that's a ton easier then my crappy way... I wonder how I never came across that stuff? Anyhew, I still learned alot about stuff, especially sudo, smbclient, passwd, and stdin. Thanks for all the help! (*Runs of dancing and jumping and throwing brightly colored bits of paper into the air*) ;D
Thanks to you I've just finished a completed script, what was that, all of two minutes?
Yeah... *rofl*
It's okay though. Easy to do. I could see myself doing just what you did.
Glad you learned some things though. And that must be why you didn't look for it... since everything has a reason to it.. in some way or another.
Glad to be of help.
This may have been noticed (or not) because I didnt read the whole thread, but I noticed something about using pipes in your code. I would be against it if it were taking any user data without being run through taint or some other checks first. Pipes leave the ability for users to repipe elsewhere and/or ; && out to another execution.
Just FYI in case that was your plan.
Thanks,
Wilnix
I didnt want to leave myself with a statement like above without an example. I wrote this in perl, but it really doesnt matter what language you choose (except that dreaded java crap)....
#!/usr/bin/perl -w
# pipe.pl
#pipe checkin proggy by wilnix
while (<STDIN>) {
system "echo hello | echo $_";
}
Run this locally and type in the following:
ass | cat /etc/passwd
and check out the results. Fun stuff...
Wilnix
Nope, wasn't what I was thinking of....
okay, I'll shut up then :-X
Wilnix
No need -- it was a good (okay, excellent) point!
What is taint?
By the way, is there a limit on pipes? Can you pipe more than once in a single line? I'm not sure if I'd ever have need to, just wondering...
http://gunther.web66.com/FAQS/taintmode.html#what
for instance.
And yes, you can use pipes more than once on the same line ...
You can redirect any combination of the outputs/inputs (stdout, stdin, stderr) as well.
Want to hear something else ? You can even use the 'tee' command to write the same output to files and stdout at the same time (which is quite useful at times). See 'man tee' (or 'info tee' if you're a info junkie).
The unix / linux shells are really quite powerful.
Word.