1

I know that both support specifying the username, which can be forced using an alias in root-owned ~/.bashrc, but one can temporarily disable the alias by prepending the command with \, so what are the options to force these programs to show the current user only when the user isn't root ? I'm clueless as to what terms to use in Google ...

In case it matters, it's Ubuntu Linux 12.04.4 on 3.10.23-xxxx-std-ipv6-64 64-bit especially created by OVH.

EDIT 0: Unless I failed with it, rsync completely ignores the environment variable which specifies the password. Using the password file option doesn't work without a Server running on the other end.

The problem with specifying passwords for scripted runs such as cronjobs is you can't, and most programs don't mask the pw (apart from wget) nor allow other methods to tell it. However, the issue at hand is to prevent these 2 programs telling the sensitive info to other users, which seemingly can be prevented by adding a setting to /proc's mount line. Once this is solved, we can move to other similar issues.

I'm still a basic Linux Admin but I'm trying to work out single systems where multiple users can work on using SSH, and that opens an array of security issues.

EDIT 1: Some programs run long enough to show up in [h]top for someone to copy, which is the root of the concern. If we assume we can trust the staff members, showing up passwords in [h]top needs to be prevented.

rautamiekka
  • 201
  • 1
    You're looking at it the wrong way -- the information in top can be found a bunch of other ways, so limiting top's output won't hide anything from anybody. See How to make a process invisible to other users?. – goldilocks Mar 16 '14 at 21:39
  • Goldilocks makes a good point, this sounds like an xy problem. What are you really trying to achieve here? – terdon Mar 16 '14 at 21:46
  • @terdon; @goldilocks: privacy on multiuser system so the passwords possibly visible on the command's startup line you see in the programs aren't shown. The linked question seems like a viable way, I'll see about it. However, SELinux haven't been in use in Ubuntu for ages, instead there's AppArmor. – rautamiekka Mar 16 '14 at 21:52
  • 1
    Yikes! Why are passwords being used on the command line? The easiest thing to do would be to change that. – goldilocks Mar 16 '14 at 21:59
  • @goldilocks: How ? As far as I see, rsync doesn't care about the password variable, and no program that likely requires a password, such as FTP, allow it via the parameters only [in the case of scripted run], like ftp USER:PASSWORD@HOST, and next are programs which don't look for the password amongst the parameters. This is one problem I have on Linux. – rautamiekka Mar 16 '14 at 22:02
  • You don't have to do it that way; see this answer (that whole Q&A may be useful). Also, I'm sure rsync/ssh will present a prompt if you don't include the password, as should anything else. I'd be really surprised to here of a common tool that requires you to put the password on the command line, although it may be an option. – goldilocks Mar 16 '14 at 22:07
  • @goldilocks: the problem is you can't give passwords to scripted runs, like cronjobs. I'm already aware of the linked answer, and it doesn't work for the very reason of not having rsync Server running, and I already tried with the env var and it was completely ignored by the looks of it. – rautamiekka Mar 16 '14 at 22:09
  • Please add all these specifics to your question. It's the type of thing you should always mention (also that you've read this other Q&A) to avoid this type of long discussion in the comments. – terdon Mar 16 '14 at 22:12
  • @terdon: the wisest person is the person who comes last. Adding. – rautamiekka Mar 16 '14 at 22:13
  • Tch. WRT to scripts, you can get use expect to automate replying to the password prompt by feeding it a password from a file. – goldilocks Mar 16 '14 at 22:16
  • Here you go: http://stackoverflow.com/questions/13095165/rsync-over-ssh-from-an-ant-script-with-a-password Note expect exits after the command is run, so it does not appear on the command-line. – goldilocks Mar 16 '14 at 22:17
  • A better one w/ expect in a script http://stackoverflow.com/a/15177797/1151724a script: – goldilocks Mar 16 '14 at 22:22
  • @goldilocks: looks interesting. One comment says it's pretty insecure though, but isn't that in the case where an evil root comes nose around ? – rautamiekka Mar 16 '14 at 22:24
  • You can't stop evil root in the case of automating authentication, I should think. This does mean you have to store the password in plain text somewhere -- but someone who can read that could read ssh keys, etc. There's no way out. Still, way better than on the command line. – goldilocks Mar 16 '14 at 22:31
  • @goldilocks: that's exactly what I meant. – rautamiekka Mar 16 '14 at 22:35
  • You can ask around, but personally I don't see any possible solution. If you are entering a password live, it isn't stored anywhere and it's transmitted encrypted (although even in this case, evil root could key log you). But in the case of not being there, you have to store something and that can't be protected from the superuser. – goldilocks Mar 16 '14 at 22:40
  • I'm not entirely sure what you mean by your edit. Is this issue solved by the mount option to /proc? If so, what are you asking? – terdon Mar 16 '14 at 22:46
  • @goldilocks; @terdon: Yes, I'm aware of that, and that doesn't worry me. Updated the OP. – rautamiekka Mar 16 '14 at 22:49

0 Answers0