Tom Mueller (plain-text) wrote:
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.
Agreed.
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.
Agreed.
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.
Depends what creating a user means. If it is updating etc/passwd inside
that image (since etc/passwd would be owned by the user in the image)
chances are that part would succeed in many cases but the chown could
still fail.
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".
Indeed such is the "flexibility" of FMAC/FLASK.
There is also the _POSIX_CHOWN_RESTRICTED option on Solaris that could
come into play here - see chown(2). Not that I recommend anyone use
that but user images is actually a possibly useful area.
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.
Yep.
Would it be better to just have a policy in the cfg_cache file for this?
I don't think so.
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 exactly that type of reason I don't think a cfg_cache option is the
way to go.
> 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?
Maybe I'm not reading the code correctly but it looks like in
pre_get_uid_gid() you pass in the user and group names to
image.can_change_file_ownership(). So can't use use that user and group
name in the chown call ?
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.
That is actually a better failure audit record than st_uid + 1 because
it is meaningful to what was happening. What is st_uid + 1 happens to
be the CFO's uid that could set of all sorts of alarm bells.
--
Darren J Moffat
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
