leamas / lpf

lpf - Local Package Factory
MIT License
61 stars 6 forks source link

Support system without sudo #19

Closed hroncok closed 10 years ago

hroncok commented 10 years ago

Hi, I'm nut using sudo and currenty I can either run lpf as user. Then I'm prompted for my password and then sudo fails.

I can run lpf as root, but then I'm prompted for my password (root) witch is pointless.

Please support PolicyKit instead of sudo, as PolicyKit supports both sudo and root password.

If you have no clue, how to do it, just run pkexec instead of sudo. It will prompt for password either in terminal or using graphical user interface dialog when DISPALY is available.

leamas commented 10 years ago

Thanks for input! Labeling as an enhancement.

Using pkexec/polkit instead of sudo is perhaps possible, dunno at this point. However, it's not as simple as running pkexec instead of sudo - lpf uses a rather fine-grained permissions system not requiring the user to be an administrative user besides for the install operation. Root privileges are also required to add user to the pkg-build group, which is the base of giving permissions to other operations.

Also, using polkit instead of sudo means that lpf will be fedora-only for the foreseeable future. Although this might be the case anyway, it requires some thought.

For now, it's just that sudo is a dependency. Are you saying that lpf does not work with a default, out of the box sudo configuraiton? If so, that's certainly plain bug.

hroncok commented 10 years ago

Well, I haven't use sudo on Fedora for ages. In the installation, I just uncheck the box Make this user an administrator.

Now lpf just drags sudo as a dependency but it doesn't work, as it ended with invalid sudo request (This incident will be reported stuff).

Pkexec is not Fedora only.

http://packages.debian.org/wheezy/policykit-1 https://build.opensuse.org/package/view_file/Base:System/polkit/polkit.spec?expand=1

With pkexec, you can also "not require the user to be an administrative user besides for the install operation".

If you have absolutely no idea, I can create pull request.

leamas commented 10 years ago

Thinking about it, I think I understand why a default sudo configuration won't work. At a minimum, this should be detected in runtime and be documented. Adding "Bug" label.

Or, perhaps handled using pkexec/polkit instead. If you could provide a patch/pull request implementing something similar to pkg-build.sudo it would certainly be interesting.

BTW, it seems that I was simply wrong assuming polkit being Fedora only. Sorry for that.

leamas commented 10 years ago

As of now, there's seemingly no way to discover if user can run a given sudo command with or without a password, making runtime tests hard to implement while still using sudo. I've posted a message on the sudo mailing list: http://www.sudo.ws/pipermail/sudo-users/2013-December/005390.html

leamas commented 10 years ago

The more I think about this, my feeling becomes that the default sudo configuration is broken. When you add yourself as an "administrative user" during the install the UID is added to the wheel group. The sudo configuration has two entries to enable members of the wheel group to run commands as root (with or without a password). However, as distributed both are commented out.

To enable the entry allowing wheel users to run as root after supplying a password by default seems reasonable to me, assuming the wheel group is empty unless user checks the "administrative user" checkbox. If so, everything should work fine. Without any administrator things will fail, but that's as expected.

OTOH, enabling sudo by default opens a new attack vector. Not everybody thinks this is a good idea.

One way could be to add the entry for the wheel group to the sudo config file installed by lpf. However, this seems a bit to intrusive....

This is not to say that sudo is the only route. I presume polkit can walk around these obstacles in other ways. However, this is extremely muddy waters for me.

leamas commented 10 years ago

Hm... Looking for other things, I found [1]. Basically, this boils down to that in a pristine installation where user checks the 'Administrator" checkbox that user will be configured to being able to run as root using sudo. This should mean that current approach should work out of the box, and that my remark about a broken default sudo setup above is plain wrong. It also makes me tempted to close this bug, unless there is more input.

[1] http://distrowatch.gds.tuwien.ac.at/weekly.php?issue=20131223&mode=67 , comment 49

hroncok commented 10 years ago

Well, but if the user doesn't check the box, this is all broken. I will send examples / patches soon, I just haven't been in the mood during Christmas.

leamas commented 10 years ago

Patches are welcome! As of now, it is really broken if you not check Administrator, agreed (unless you read the manpage and does what is says, not likely if you're not administrator).

EDIT: If you make patches, please rebase to devel branch. It's now feature complete.

hroncok commented 10 years ago

The problem here is, that I just don't want my user to be in sudousers as I don't like the approach.

However, as said before, pkexec will work for users with sudo and for users without it, so it would be more flexible.

leamas commented 10 years ago

One could of argue that it's not possible to support all kinds of configurations. Still, as of current we run into a basic sudo limitation: if you ask for what kind permissions you have without any permissions at all there will be a prompt. This seems to be by design and probably not gonna change.

So, if you could provide some polkit-based patches they would be more than welcome!

leamas commented 10 years ago

Hm... this might be dead simple. Pushed a branch polkit which seemingly solves the problem by using pkexec when adding current user to pkg-build group, keeping sudo to handle permissions once user is added to group.

This will not add any general permissions to run as root, only some specific combinations of user, script and arguments granted to the pkg-build group.

hroncok commented 10 years ago

Oh, great. So now the user is added to the group in the first run and after log in and log off he is capable of doing everything withoud having the admin sudo rights?

leamas commented 10 years ago

Yup, if things work as they should. Would of course appreciate if you could make a test run... BTW, seems that I slipped on the keyboard, the branch name missses a letter...

LaKing commented 10 years ago

I'm getting asked for password even as root user. Maybe i opened this issue as a duplicate of this bug/issue.

leamas commented 10 years ago

This is by design - the installed sudo config file will override other definitions being the last match. And that policy is to allow each and every operation for users in pkg-build group without any password besides the final installation which indeed requires one.

I still feel this is a sensible default. And the sudoers configuration is indeed configuration which could and should be modified for local needs. However, when doing so you must either remove the sudoers.d/pkg-build file or patch it since it's the last match.

Closing after having implemented issues reported by hroncok and deeming LaKing's issue as not-a-bug. Please feel free to file a new issue if you feel this is appropriate.