On 2013-12-10, Canek Pel??ez Vald??s <can...@gmail.com> wrote:
>> But the example provided only shows how to grant capabilities to a
>> user that can then be inherited by files which must also have that
>> same capability enabled. That's not quite what I want to do (and it
>> doesn't seem to work).
>
> The restriction to files already having the capability is for security
> reasons, obviously: if a user has certain capability, and she forgets
> to change the others access to some executable, then anyone has the
> capability (if I understand correctly).
No, that's not how it works. You can use pam_cap to grant an
inheritable capability to a user, but it can only be used by files
that also have the capability to inherit that capability.
There are basically two ways you can set a capability on a file: the
file can have the capability regardless of the user, or the file can
have the capability only if it can be inherited from the user.
If you grant a capability to a file using "setcap cap_whatever+ei
myprog" then it's only effective for users that also have cap_whatever
enabled in /etc/security/capability.conf
If you grant a capability to a file using "setcap cap_whatever+ep",
then it's available to all users.
> Again, create an executable with CAP_SETPCAP that executes the Python
> programs and sets the capabilities for the running program.
[...]
> You can create (once) an executable with CAP_SETFCAP, which your
> build system calls automatically every time you recompile and that
> sets the CAP_NET_RAW capability for the resulting executable. Not
> very secure anyway, but I think it could work.
It's a lot simpler to just continue using sudo to run the programs.
>>> A workaround for what you want is to write a little executable that
>>> only execvp's bash (or whatever shell you use), grant that executable
>>> CAP_NET_RAW, and then set it as default shell with usermod.
>>
>> I thought about that, but that seems fragile.
That wouldn't help. I've figured out how to give bash CAP_NET_RAW
capabilities for a specified user, but it still requires that
executables have the same capability set.
>> I supposed I could set the capability on /bin/bash with +p instead of
>> +ep, then it should only take effect for users who have the capability
>> enabled (though I haven't been able to get that to work yet).
That doesn't work either. Bash gets the privledges in question but
they aren't inherited by programs invoked by bash unless they have
already had those capabilities set.
> I think the problem is that you want to use capabilities in a way that
> they are not designed for:
Apparently so.
> you don't set capabilities at development time, you do it at
> deployment time. I would develop in a container or a VM until the
> program is ready and then deploy it with capabilities enabled.
No, that's not the problem. The problem is that the whole system is
designed to assign capabilities to _files_, and I want to assign a
capablity to a user.
--
Grant Edwards grant.b.edwards Yow! BELA LUGOSI is my
at co-pilot ...
gmail.com
