Username & password in environment variables for CLI?

0 views
Skip to first unread message

Ron Michael Zettlemoyer

unread,
Mar 21, 2013, 3:41:56 PM3/21/13
to sta...@clarkparsia.com
I was just looking over some of the notes for the nice new CLI we're going to see in 1.2 and was thinking to myself how annoying it is to have to keep providing a user name & password.  The AWS CLI allows you to store your access key and secret key in environment variables. Could you do something like that for the Stardog CLI?  It may be too simplistic or insecure for some scenarios but in many cases I think it'd be quite useful.  It could also eliminate having to add the admin password to the Windows service shutdown scripts.

Kendall Clark

unread,
Mar 21, 2013, 3:43:57 PM3/21/13
to stardog
On a real shell, users can do it, no?

$ export u=ron
$ export p=shinyHappyFunTime

$ stardog-admin -u $u -p $p ...

No?


On Thu, Mar 21, 2013 at 3:41 PM, Ron Michael Zettlemoyer <ron.zet...@fynydd.com> wrote:
I was just looking over some of the notes for the nice new CLI we're going to see in 1.2 and was thinking to myself how annoying it is to have to keep providing a user name & password.  The AWS CLI allows you to store your access key and secret key in environment variables. Could you do something like that for the Stardog CLI?  It may be too simplistic or insecure for some scenarios but in many cases I think it'd be quite useful.  It could also eliminate having to add the admin password to the Windows service shutdown scripts.

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en
 
 

Ron Michael Zettlemoyer

unread,
Mar 21, 2013, 4:21:52 PM3/21/13
to sta...@clarkparsia.com
Yes, but what I meant was that we pass nothing at all in the CLI. We just pass it the commands and it automatically pulls the username and password from some environment variables like STARDOG_USERNAME and STARDOG_PASSWORD.

Kendall Clark

unread,
Mar 21, 2013, 4:25:09 PM3/21/13
to stardog

I know but my solution plus alias already works and is almost as good. :)

Kendall Clark

unread,
Mar 22, 2013, 9:42:32 AM3/22/13
to stardog
On Thu, Mar 21, 2013 at 4:21 PM, Ron Michael Zettlemoyer <ron.zet...@fynydd.com> wrote:
Yes, but what I meant was that we pass nothing at all in the CLI. We just pass it the commands and it automatically pulls the username and password from some environment variables like STARDOG_USERNAME and STARDOG_PASSWORD.

This is just so terribly insecure that I'm not sure it's worth doing...

Cheers,
Kendall

Ron Michael Zettlemoyer

unread,
Mar 22, 2013, 10:31:53 AM3/22/13
to Stardog
Terribly insecure, like embedding the Stardog admin password in the Windows service shutdown batch file?

I agree that it's a bit insecure. But again I go back to the AWS CLI. You can embed your access key and secret key in the environment so that you don't have to keep passing it on the command line. If someone grabbed them they could do a lot of damage to your account. So Amazon either feels that those risks are minimal or worth it.

Windows has user environment variables and global system environment variables. I assume Linux and OS X have the same? So if you embed your user name and password into the user variables, they should be pretty secure from someone else getting into the same computer.  (Assuming that the OS protects that information so it can't be easily hacked into by other accounts) Now if someone hacks into your account, or if you run some rogue software that grabs the data from your environment, well...  someone with the right permissions could just erase or corrupt your Stardog files anyway, or copy them off to a remote site and hack into them.

Ideally I'd love it if Stardog could somehow be aware of local user accounts. Or if you could tie it into an organization's LDAP or something like that. Or some way to recognize that someone running the command line locally is an admin.





--

Kendall Clark

unread,
Mar 22, 2013, 10:56:01 AM3/22/13
to stardog
On Fri, Mar 22, 2013 at 10:31 AM, Ron Michael Zettlemoyer <ron.zet...@fynydd.com> wrote:
Terribly insecure, like embedding the Stardog admin password in the Windows service shutdown batch file?

Yes. I take yr point that this wouldn't be *more* insecure, but there is a difference: we don't recommend running Windows in any environment other than development. Security is less crucial there.

But using env vars on a Unix box makes *production* usage more insecure and that's not very prudent.

As I said, though, with the right use of Unix alias command and environment variables, you can totally hack this to support what you want *today* without waiting on us to do it. :>
 
I agree that it's a bit insecure. But again I go back to the AWS CLI. You can embed your access key and secret key in the environment so that you don't have to keep passing it on the command line. If someone grabbed them they could do a lot of damage to your account. So Amazon either feels that those risks are minimal or worth it.

Amazon probably has better insurance than we do. :>
 
Ideally I'd love it if Stardog could somehow be aware of local user accounts. Or if you could tie it into an organization's LDAP or something like that. Or some way to recognize that someone running the command line locally is an admin.

We're working on being able to delegate authentication to 3rd party services like LDAP, etc.

Cheers,
Kendall 

Andrew Simms

unread,
Oct 28, 2013, 7:56:21 PM10/28/13
to sta...@clarkparsia.com
Any update on this?  Using shell variables for username/password prevents these from appearing in system logs.  I'm happy with some sort of delegation facility if that is coming soon.

Thanks,

--Andrew

Kendall Clark

unread,
Oct 29, 2013, 8:54:16 AM10/29/13
to stardog
Delegation would be via the Apache Shiro system we use. We haven't done that yet but only because so far no one's really indicated very strong need for it.

Cheers,
Kendall


--
Reply all
Reply to author
Forward
0 new messages