'askpass'

I am taking steps to setup sudo. rootfs-skeleton/etc/sudoers in Woof is starting to take shape. I have specified 'mp' as the text editor for 'visudo'. I have set /usr/sbin/askpass as a GUI helper when a password is needed by sudo. These are some entries that I have put into /etc/sudoers:



'askpass' is a little script that I knocked up using gtkdialog. It asks for the administrator (root) password, which gets returned on stdout.

I think that sudo has to be invoked with the '-A' option for askpass to work, for example:

# sudo -A pmount

...theoretically, haven't tried it yet!

---

Comments

sudo won't accept password
Username: BarryK
Hmmm, got a problem. Testing running fido, sudo will not accept the root password, says it's wrong. However, 'su' accepts it. 'su' is a Busybox applet, and Busybox has its own internal password handling code, whereas probably sudo is using glibc. There is some kind of mismatch here.

having fun with sudo
Username: L18L
"Barry, here is what I have got so far... # sudo pmount Password: You gotta go owwwww! Password: It's only your word against mine. Password: Wrong! You cheating scum! sudo: 3 incorrect password attempts # # # sudo pmount Password: My pet ferret can type better than you! Password: BOB says: You seem to have forgotten your passwd, enter another! Password: You speak an infinite deal of nothing sudo: 3 incorrect password attempts # hehe, and another # su spot # mount -t ext2 /dev/sda2 /mnt/sda2 mount: only root can do that # sudo mount -t ext2 /dev/sda2 /mnt/sda2 Password: The more you drive -- the dumber you get. Password: It can only be attributed to human error. Password: You silly, twisted boy you. sudo: 3 incorrect password attempts # Silly me, my askpass: [code]#!/bin/sh echo "password: " read -s echo $REPLY[/code] I am sure it is not working. But anyhow a funny thing

gksudo
Username: Dougal
"Barry, wouldn't it be simpler to just use gksudo? http://www.nongnu.org/gksu/

Sudo doesn't work
Username: BarryK
"Dougal, Gksu has a lot of Gnome dependencies. Last night I recompiled sudo, as I thought maybe the absence of PAM could be upsetting password recognition. I configured with '--without-pam', and re-uploaded the PETs. Unfortunately, sudo will not recognize the root password still. I tried with telling 'chpasswd' to generate DES and MD5 encrypted passwords, neither work. I tried with the chpasswd from the 'shadow' package instead of busybox, still no-go. It is a mystery, how can sudo be so dumb? /etc/shadow is right there. This is my configure options: [i]./configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib --datadir=/usr/share --includedir=/usr/include --infodir=/usr/info --mandir=/usr/man --sysconfdir=/etc --localstatedir=/var --disable-debug --enable-log-host --disable-pam-session --build=i486-t2-linux-gnu --with-nsswitch=no --with-netsvc=no --without-pam --without-sendmail --without-lecture[/i] Well 1.7.2 is not the latest sudo, it is the version used when I compiled in T2. I will now try the latest. And, maybe try a very old version.

sudo?
Username: scsijon
"I suppose it's not looking for it in shadow rather than passwd and shadow has not been updated correctly? latest stable sudo=181p1, there are an awfull lot of fixes after 172, even maintenance minimum is 176p1 also sudo requires a valid shell to be in the password database, su defines it's shell requirement. Not missing or wrong (permissions, etc), is it? just a thought

gksu without the crust
Username: technosaurus
"https://github.com/nomius/ktsuss its fast and light and stands for: "keep the Su simple stupid"

Sudo works!
Username: BarryK
":cry: :happy: So many times I have recompiled sudo, tried different versions. Then I was reading a link posted by scottman: http://bkhome.org/archive/blog2/201105/sudo-172.html Extract from link: [i]Once again nothing obvious showed up. At this point I started Googling to try and find the answer. There was a lot of articles about people trying the root password rather than the user password, but I wasn’t doing that.[/i] The thing is, 'fido' does not have a password, so sudo should just accept the ENTER key, but it doesn't. Because that did not work, nor the root password, I was stumped. However, after reading the above, I used 'chpasswd' to give fido a password, and voila, it works! Now, if I just put this at the beginning of a script, for example in /usr/sbin/pmount: [i][ "`whoami`" != "root" ] && exec -A ${0} ${@}[/i] ...pmount works like a charm. The -A option causes my askpass GUI to run. Can anyone think of any reason why this solution at the beginning of certain scripts is not a good idea?

Correction
Username: BarryK
"Sorry, that should have been: [i][ "`whoami`" != "root" ] && exec sudo -A ${0} ${@}[/i]

Tripple post - sorry
Username: zygo
"I blame Opera mini. There's no way to refresh a page without re-submitting it -- even after required fields are blanked! The caveats section on the man page may be of interest too.

Re triple post
Username: BarryK
"I just deleted the redundant two posts, just before your Opera mini explanation! Yeah, I think that other people who have double-posted to my blog, were using Opera.

Puppy babushka-doll nests?
Username: CLAM01
"I would like to suggest that setting up sudo in puppy is purposeless, not even 'gilding the lily', because it is more akin to 'bleaching the lily', adding no gold, only an artificial aroma. For appropriate disclaimer, I am not a sudo fan. On single-install multi-user systems I use root log-on only to access core programming, never going from a user account. I have never run a ubunto because I don't like its sudo administration system. In puppies one does not run as root, even when 'running as root', because real root in puppy is locked in the primary sfs file. In a puppy as root one is pseudo-root. To log in to a puppy as real root and adjust a puppy's core programming one must run the 'remaster' program. Remastering a puppy one makes a new puppy root primary.sfs. Modifying one's running puppy, adding pets and access to sfs applications, one modifies his personal user environment. The root sfs remains unchanged. If a user screws up a puppy, even beyond what a pfix=clean or purge restart can repair, it is still only the user's personal account that is screwed up. The root system primary sfs remains unchanged. So the user can restart pfix=ram, open-mount his wrecked user-save personal account file, delete what he wrecked, if he knows, or everything, then click-unmount and reboot. The mastered puppy sfs is root and builds a new puppy 'user account' to its mastered spec. I agree with pizzagood about options. I also like browsing as user-spot. A puppy install is a 'sandbox; it can absorb whatever lands. a browser in user-spot adds a "liner" to the puppy sand-box. The liner can catch whatever comes in, leaving the 'user-account' clean and easy to routinely clean: Just lift out the user-spot 'liner', toss, reinstall a clean spot. Browser settings set in root are still set and needn't be reset.

Tags: woof