chown: invalid group: ‘com-sixs:com-sixs’

Hello Joey

I try to use

Ssh.authorizedKey (User "com-sixs") sshKeyPubComSixs

on a system where the account are available in a ldap. On this system the group is different from the user name name -> grp-name

So I end up with this error message

chown: invalid group: ‘com-sixs:com-sixs’
sixs3.exp.synchrotron-soleil.fr com-sixs has authorized_keys ... failed

so my questions are.

Is it mandatory to have a user and the identical group on a unix system ?
Can we add a Group parameter to the authorizedKey property ?

thanks for your help

Fred

RSS

comment 1

something like this

-- | Ensures that a user's authorized_keys contains a line.
-- Any other lines in the file are preserved as-is.
authorizedKey' :: User -> Group -> String -> RevertableProperty UnixLike UnixLike
authorizedKey' user@(User u) grp l = add <!> remove
  where
    add = property' (u ++ " has authorized_keys") $ \w -> do
        f <- liftIO $ dotFile "authorized_keys" user
        ensureProperty w $ modAuthorizedKey' f user grp $
            f `File.containsLine` l
                `requires` File.dirExists (takeDirectory f)
    remove = property' (u ++ " lacks authorized_keys") $ \w -> do
        f <- liftIO $ dotFile "authorized_keys" user
        ifM (liftIO $ doesFileExist f)
            ( ensureProperty w $ modAuthorizedKey' f user grp $
                f `File.lacksLine` l
            , return NoChange
            )

modAuthorizedKey' :: FilePath -> User -> Group -> Property UnixLike -> Property UnixLike
modAuthorizedKey' f user grp p = p
    `before` File.mode f (combineModes [ownerWriteMode, ownerReadMode])
    `before` File.ownerGroup f user grp
    `before` File.ownerGroup (takeDirectory f) user grp

then it is trivial to rewrite the previous properties

but I do no know if this is the right path to follow.

Comment by picca — Wed Feb 13 11:33:20 2019

Remove comment

comment 2

Make that into a git patch and I will merge it.

However.. If you git grep userGroup you will find all the other places that propellor assumes a user-group system. Seems it would be worth fixing those too, especially the other ones in Ssh.

Seems like another approach to it could be to make userGroup's behavior configurable based on another Property of the Host that sets Info containing say, a function from User -> Group. Looks to me that would be doable, if a little bit annoying since userGroup would need to change from a pure function to a Propellor action in order to use askInfo.

Comment by joey — Wed Feb 13 21:48:30 2019

Remove comment

comment 3

Thinking more about a hypothetical property like userGroupFunction (\User u -> Group (u ++ "-group")) the idea seems problimatic because all the properties that install a package with a dedicated user and group would seem to need to be changed to support putting the user in the group configured by the property.

I suppose it could be documented to be limited to non-system users and groups, so only User.accountFor would need to support when making users and groups, and Ssh.userKeyAt etc would use it to tell what group to use for a non-system user.

Although, is Ssh.userKeyAt etc really limited to being used with non-system users? Perhaps User should have an additional SystemUser constructor to encode the distinction. Or perhaps this idea of mine is going in the wrong direction.

Comment by joey — Sun Feb 17 18:07:39 2019

Remove comment

Add a comment