All ideas and thoughts here .
16:05 msavy: if we change the privilege levels (e.g. user -> root) half way through the program
16:06 msavy: then back again,
16:06 msavy: would there be problems with the user being repeatedly prompted to enter the password
16:07 mgoldmann_: I'm not sure how we could change the user - executing sudo when running appliance-creator?
16:09 msavy: bbrowning, bobmcw_: your thoughts guys. what is the best/most seamless way to change privileges within the program, without inconveniencing the user.
16:10 msavy: 16:01 danpb: can't you run mostly unprivileged, then internally run sudo for the privileged bit
16:10 msavy: 16:01 fidencio is now known as fidencio[AWAY]
16:10 msavy: 16:01 danpb: so when you need to connect to remote libvirt, you're in the unprivilegd bit
16:10 bbrowning: I believe bundler sets a precedent for this in Ruby apps by executing sudo on behalf of the user
16:10 bbrowning: not that you should necessarily copy bundler
16:10 msavy: it'd make life easier for SSH/SFTP plugins too, as the user's normal environment would be available
16:11 msavy: bbrowning: but at some point the user would need to enter their password surely? to authorise the su?
16:11 bbrowning: msavy: well, unless you're like a lot of people that have passwordless sudo
16:11 bobmcw_: NOPASSWD ftw
16:11 bobmcw_: but yah, capistrano will prompt for passwd if required, also
16:11 bbrowning: I'd say detect if you're not root and attempt to sudo on the user's behalf
16:12 bbrowning: Then users have the option of running everything as root, using NOPASSWD and sudo, or having to enter their password a few times
16:13 bbrowning: and just in the docs state you'll want to run as root or NOPASSWD sudo for unattended builds
16:13 msavy: hmm.
16:14 msavy: i was hoping that somehow you could start with normal user, raise instantly to sudo (and hence prompt for password), and at that point you could freely escalate/deescalate without needing further password approval.
16:14 msavy: interesting
16:15 msavy: thanks for your input bbrowning
16:16 bbrowning: msavy: yeah, sudo lets you do that if setup properly
16:16 bbrowning: you can setup sudo so that it only requires a password once every X minutes or whatever
16:17 mgoldmann_: detecting root priviledges makes sense I think
16:17 mgoldmann_: we can detect if this is a sudo root or normal - if sudo chown the files for regular user
16:18 mgoldmann_: and proceed to next plugins with normal rights
16:18 msavy: does guestfish need root perms?
16:18 mgoldmann_: the easy thing is that we execute appliance-creator in shell where we can use sudo if needed
16:18 mgoldmann_: no
16:18 msavy: that's good
16:18 mgoldmann_: and this is great
16:19 mgoldmann_: msavy: feel free to create a jira - it's a 5 line fix
16:19 msavy: okay
16:21 msavy: that'd make our lives easier on a few different levels
16:22 msavy: and not confusing the user is always good
16:22 mgoldmann_: but sometimes it'll require intervention of the user (visudo)
16:22 mgoldmann_: this needs to be very well documented
16:22 mgoldmann_: very well
16:23 msavy: hmm, if it requires any intervention then i dunno if we should do it. i'll make a ticket, then ask around a few people, have a read around. hopefully we can make a good choice.
solves the following problems(s):
- SSH_AUTH_SOCK becomes available, so ssh-agent can be used by ssh, sftp and libvirt ... libvirt offers no way currently of manually giving keys for auth
- less confusing to users who seem to expect it to be using their local environment for things such as the above, and file ownership