Darren J Moffat wrote:
Tom Mueller wrote:
Shawn Walker wrote:
Tom Mueller (plain-text) wrote:
pkg(1) now prints a message and returns 1. However, for a user
image where the user is unable to change the ownership of a file
anyway, not having the required user/group is ignored.
I don't agree with the assumption that a user image automatically
implies that a user doesn't have the permissions to change ownership
of a file.
With the change, the Image class has a "can_change_file_ownership"
method that tests to see if the user running the command actually has
the ability to change file ownership within the image. This test is
only done for non-ENTIRE images. Only if it is a non-ENTIRE image AND
the user cannot change file ownership of a temporary file are invalid
owner/group tags ignored.
AFAIK, I'm not making the assumption that you don't agree with.
While you aren't making that assumption the test you are making isn't
completely reliable in all cases on all platforms.
The issue is that you can't actually assume that because you managed
to do a chown of a temp file you created you can do that to any future
file in that image directory tree.
I also really don't like the idea of chowning a file to st_uid + 1 -
if feels icky, and worse the failure will raise audit records that
look really suspect if auditing is turned on.
On a system running FLASK/FMAC (aka SE Linux) chown could be
constrained so that I could do the chown to the users that I need to
yet the "st_uid + 1" trick would have failed. While that is SE
Linux only just now FMAC is being ported to OpenSolaris too -
http://opensolaris.org/os/project/fmac/
For example you rules like "bob can chown to alice and carl, but can't
chgrp out of his supplementary groups" are possible in an FMAC config.
Your test would likely not catch that. Not currently possible to
easily configure this on OpenSolaris today but with FMAC it is trivial
(well modulo FMAC's own rule complexity issues).
You make good points here, but I'm not sure how to proceed.
An improvement would be to check if you can chown and chgrp files to
those the plan actually needs - while that still isn't perfect it
would require a pretty tight FMAC configuration to trip that up.
At the time that this check is made, there is no guarantee that the plan
even needs to make any changes of ownership. So there isn't any good uid
or gid to use.
Consider this case:
A non-root user attempts to install a package into a user image that
contains a single file action, with "owner=blah", where "blah" is not a
current user on the system. Therefore, we don't have a uid for "blah",
so we cannot attempt a chown. At this point, we want to determine how
to deal with this error situation (rather than raising a KeyError
exception as we do today).
Let's assume that this user isn't able to change file ownership anyway,
and since the user cannot even create a new user, it seems to be
unreasonable to raise an error that prevents the package from being
installed. Especially since had the user existed, the file ownership
still would not have been set anyway and the package would install
successfully. We don't want to automatically consider a user image to
not be an error because it is possible for root users to use user
images, and for that case we want to require the right users. So the
question we want to ask is, if this unknown user had been defined, could
we have assigned file ownership for that user? If no, then it really
doesn't matter whether the user was defined or not, we should just keep
going.
Also, we really want to ask if the user running the command is able to
create a new user, so that, if they can change file ownership, they
would eventually be able to get the package installed.
And from what you've pointed out about the possibilities with SE Linux
and FMAC, no matter what we do in the code, the answer may be "it
depends on how the rules are setup".
We can't use any files that have already been installed into the image,
because the file we are installing might be the first or only file in
the image.
Would it be better to just have a policy in the cfg_cache file for this?
One problem with a policy is that the webstack team would like to be
able to distribute a single pre-installed user image file that works for
both root* and non-root users. For root usage, package installation
would insist on having the right users (apache, etc.) created. For
non-root usage, the file would be just owned by the user. So an
automatic check for the ability to change ownership is more desirable
for that case. Maybe the long term solution here is to say that this is
just not possible, i.e., the actions have to be shipped with with or
without owner/group tags, and if they are there, then the users must exist.
* By "root user" I mean a user with appropriate authorization to create
users, change file ownerships, etc.
Would it be acceptable to attempt a change in ownership to uid=0, gid=0
instead?
This would still trigger audit records, but currently we ship packages
for user images with owner=root group=sys, so there are attempts to
change ownership to uid=0, uid=3 already when packages are installed by
non-root users into user images.
Your suggestions would be greatly appreciated.
Thanks.
Tom
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
