Username contains invalid characters about bless HOT 6 CLOSED

The rule giving you issues is controlled at:
https://github.com/Netflix/bless/blob/master/bless/request/bless_request.py#L11

Linux Distributions have a mixed bag of allowable usernames.
See the Caveats of
http://man7.org/linux/man-pages/man8/useradd.8.html#CAVEATS ( most restricted )
http://manpages.ubuntu.com/manpages/trusty/man8/useradd.8.html ( suggested to use most restricted rules, but allows more )
http://linux.die.net/man/8/useradd ( most permissive )

I wouldn't object to a config that controlled which of the 3 regex patterns validated usernames.

from bless.

@russell-lewis I have a use case where I want to be able to provide certain characters, e.g. '@' or '.' (I want to pass an email address as bastion_user to BLESS). Currently, that is not possible. I was thinking about introducing the flag to turn the username validation on/off. However, I am not sure if such functionality would be accepted nor how to tackle it.

I can easily introduce new directive in the configuration file, but bless_request.py does not touch the config file. I can introduce it and do something like:

VALIDATE_USER = config.get(VALIDATE_USER)

def validate_user(user):
    if VALIDATE_USER:
      if len(user) > 32:
          raise ValidationError('Username is too long.')
      if USERNAME_PATTERN.match(user) is None:
          raise ValidationError('Username contains invalid characters.')

However, I don't consider this to be a good solution. I have looked at marshallow documentation on how to extend the schema with new attributes (https://marshmallow.readthedocs.io/en/latest/extending.html) and maybe that would be acceptable. What would you suggest?

from bless.

@russell-lewis ping

from bless.

@xen0l it looks like @diasjorge has gone ahead and taken an approach along the lines of what you were trying to avoid. I agree with you that using schema.context to control the validation would be more desirable. Next week I should have some time to take a pass at enhancing #43 accordingly.

from bless.

It looks like there are use cases for the following validations:
The current useradd behavior.
A relaxed debian behavior. (This would work for @diasjorge and @Nr18 )
An e-mail validator. ( Can use Marshmallow's fields.Email )
Disabled validation. (Fields.String, no length checks)

from bless.

This issue should now be resolved in master.

from bless.