#!/bin/bash
#
su
gawk -F: '{ print $1 }' /etc/passwd
/usr/bin/neat


Heya all....the above script is wrong lol. What I'm trying to do is automate the task of su-ing to root
entering the password
running the /use/bin/neat command (neat is the Red Hat network setup utility)

each time i reboot I have to activate my wavelan card, as it doesn't work correctly if it's init'd at boot. This will open the network setup dialog and all I have to do is hit the activate button.

can anyone answer these 2 questions for me:
is the second field in /etc/passwd the password?
how should I print only the first entry of the selected field to the term instead of all entries?

I appreciate any and all comments.

A few problems:
1) You will need to use "expect" not "bash" to interact with programs
2) The password is probably encrypted and a user shouldn't see the file so you can't read it from the password file.

A few solutions:
1) Put the comamnd at the end of rc.local (I'm not sure if this is what you tried. If this didn;t work maybe you need to include some sort of delay for some reason before the comamnd is run)
2) Set up ssh authentication keys and ssh back to the box as root without requiring a password (this is a bit dangerous).

IMHO you would be far better off trying to determine *why* your wavelan can't be initialised properly on boot and won't come up instead of trying to find a workaround like this.
Maybe posting a new thread with enough details (setup, configs, logs, errors) in the Wireless or Hardware fora may help.

Can't you just set the suid bit on the neat program.
chmod u+s /usr/bin/neat

1. No the second field in /etc/passwd will be an x if the account is password protected and will be blank otherwise. The password is most likely stored in /etc/shadow and like mentioned above it is encrypted.
2. Use grep first to find the entry: grep user /etc/passwd|gawk -F: '{ print $1 }'

"Can't you just set the suid bit on the neat program.
chmod u+s /usr/bin/neat"
"/bin/bash": do you know if running "neat" in setuid mode is safe? If you answer "yes", do you know that from a code audit? Just guessing? Else if you answer "(dun)no", do you know if setting an app setuid is a generally accepted and safe practice?

I simply presented an alternate solution to those already posted. If you have information that it is safe or not to run neat (suid) then please provide that information. I'm sure Col Panic would appreciate it and I would too. In case you missed it I posed the solution as "Can't you" which is a question, not as "IMHO".

Running a program suid is not that uncommon. pppd is quite often run suid. If you want to allow users to burn cd's then you probably have several binaries suid. As for neat, I don't use the program but I also don't do code audits. Personally I think putting an unencrypted password in an expect script is far more dangerous, but that is MHO.

And as for this Else if you answer "(dun)no", I don't care if you are a moderator, you don't need to talk to me that way. I'm here trying to help people learn to use Linux. You may think my replies are "dumb" but I at least answered the 2 questions Col Panic asked.

And as for your problem Col Panic;
Try restarting networking after booting up and see if that helps.
service network restart
If that works then probably all you need to do is number the symlink that points to /etc/rc.d/init.d/network a little higher so it is activated later in the boot process. Also you can try the opposite and name the symlink with a smaller number to make it activate sooner.
The symlinks are in the /etc/rc.d/rcX.d directory, where X is the runlevel you are booting to.

In case you missed it I posed the solution as "Can't you" which is a question, not as "IMHO".
Offering it in any way w/o pointing to hazards is good enough for me.


Running a program suid is not that uncommon. pppd is quite often run suid.
Running an application setuid that was not meant to be run setuid is a hazard. Hell, running an application setuid that was coded to be run setuid could still pose a hazard. I'm trying to make you think about "doing it the easy way" and possible consequences. If you don't know if an application can be run setuid relatively "safely" then a warning is appropriate.


And as for this Else if you answer "(dun)no", I don't care if you are a moderator, you don't need to talk to me that way.
Like I already said I'm just trying to make you think for a second about what you're offering and it's possible consequences. If you only manage to object against how the message is presented but fail to address what I'm on about that simply shows you'd rather kill the messenger instead of looking at the message.

Setuid means any user is able to run the application with the privileges of the file owner. Anything it does it does with the capabilities of the files owner. Say you got an app that creates predictable tempfiles, then the minimum thing any unprivileged user with malicious intentions could try is to perform symlink attacks. If it doesn't create predictable tempfiles, then maybe it could be tricked into (over)writing crucial (system) files or executing commands if it for instance doesn't properly check user/env input and on and on and on.

Regardless of the problem of setuid/setgid being known for as long as it's a feature, regardless of the existence of "secure programming" tutorials, and regardless of the continuing load of crackers being able to exploit these conditions, in 2003 anyone can still find apps being shipped setXid and so allowing another security risk.


That's why I said he should troubleshoot the cause and not go for a workaround that only addresses the symptoms.

You present generic arguments against running programs suid without presenting any specific evidence that the program in question poses any particular threat.

And if you fail to see how being rude, leetest and obnoxious actually helps no one then, I thinks maybe you just like being ignored... DONE!

Sorry unSpawn is a moderator/admin and you are not allowed to ignore him or her.
Oh but you are wrong about that.

I'm starting to see why this place has so many threads go unanswered. Hell you're expected to do a code audit before you post a "suggestion?"

Thanks everyone for the suggestions and opinions.

I can't set the wavlan card to init on boot because of resource conflicts with the firewire port. I don't use the firewire, but the cruddy BIOS on this puter (Sony Vaio laptop) has no way to turn it off or to change to non plug and play. I've even had to do it this way in other OS's (windows and OS/2) and talked with Sony tech support about it. One of the more helpful tech's (Brian Kerry if anyone needs Sony support) is trying to send me a nice little flash update for the bios. Until then I'm stuck doing it this way. After Linux shuts down the firewire services and frees the resources I'm good to go.

Maybe I'm going about this the wrong way, and the current suggestion about sudo 'ing neat looks like it is in debate so I'll hold off on that one for now.

ANY AND ALL suggestion are appreciated and welcome!

EDIT
And yes bin/bash answered my questions in a complete and logical manner without trying to dumb it down. I appreciate that much.

I don't have firewire so all I can do is guess.

How are the firewire services being started? If the initscripts are doing that then you can disable it:

/sbin/chkconfig --list |grep fire
Now if you see firewire listed then do this:
/sbin/chkconfig --level 12345 firewire off
service firewire stop
Otherwise it may just be a module that is loading and you can disable it by commenting out the line in /etc/modules.conf. Or possibly you can add a line in /etc/rc.d/rc.local like this:
rmmod firewire
service network restart

I apologize to Col Panic for making an off-topic reply. And BTW this reply is not directed at /bin/bash.

Except for posts marked as LQ moderation business (which no one is allowed to ignore), any of my posts can of course be conveniently ignored: as far as regular posting is concerned, I am just another LQ member. What should not be ignored is the fact that setting apps setuid that where not meant to be run that way, or for which you don't know if they where coded with setuid operation in mind, is a security risk. That is all I'm trying to warn about, the rest is utterly unimportant.

Thanks everyone the problem is fixed.
The resource conflict between the wavlan card and firewire wasn't a linux specific issue. It happened at power on, and could only be fixed after an OS booted .....bad firmware and hardware config plain and simple.

How did I fix it?

Opened Laptop case and un-soldered 2 wires and an IC. Until I get a new BIOS it can stay that way.

Back to basics - I like it