I still think it's unclear, not off-topic. (It's closed now, as unclear.) If they give more details we can know. Perhaps they are installing packages meant for Debian on Ubuntu. That usually works, but sometimes causes problems.

I don't think that question is no repro. Their answer is bad -- you shouldn't run Android Studio as root -- but it's a recent question and nobody has asked for more information about how they installed it (though I'll do so shortly). The problem didn't go away mysteriously.

Oh, well you can come back tomorrow. Or if you think it should be closed, then you can still cast a close vote on it, just not through review. Anyway, you don't have to review it to answer it, if you so choose. :)

I just noticed another Bash post of mine that needs fixing, and I won't likely get around to posting other answers (unless they're very simple) until I've done that. But if this can be considered on-topic and answered, then it's probably best to do that. Also, the topic of fonts in Ubuntu is actually not something I know a great deal about.

It seems to me that this question should be closed as a duplicate, or answered, or commented on to request specific information (in which case the "unclear" close vote might be correct, depending on what information is requested), but that it should not otherwise be closed.

@Videonauth This is with full disk encryption (LUKS)? I thought you were testing encrypted home directories.

(Because that's what the answer you had commented on was suggesting to use.)

@Zanna Actually, never mind. It's not NTFS. They accidentally deleted their "main partition" when they went to "reinstall Ubuntu," so it's an Ubuntu system partition (ext4). So the question is clear after all.

@Videonauth I think that post is just on the "Looks OK" side of the line, and that's how I've reviewed it. Your edit definitely helped. But would it be useful for us to request more (specific) information?

Although I understand the reasoning for why it might be, I don't think this question is too broad. If it were just worded differently, it could have explicitly asked for all that stuff and been far less likely to attract "too broad" close votes. It's effectively asking two different things... but the OP and other readers would have to already know the answers to both in order for it to make sense to ask them separately.

A possible counter-argument is that the two things it's asking could be answered separately... but it would be hard to do so. It's asking what sets PS1, and also why there's no export line for it in a startup script. Your answer, @Zanna, answers the first part.

@EliahKagan regarding that statement that every user gets an encrypted home directory if you choose encrypted home for the main user on install, that is NOT true, my test user has a completely unencrypted home

> Previous answers don't apply fully, if you marked encrypt home folder while installing Ubuntu. This guarantees encrypted home folders for every user, even so root can't read the data without the proper password of the user/owner of that home folder.

Perhaps the answer could be edited so that it specifically describes the actual behavior. Certainly it's possible to create new users with encrypted home directories, so the basic technique should work so long as one actually does that. I think such an edit would be just inside the line of how much it is reasonable to change someone else's answer; if the information can be given correctly, I'd say go for it.

There does remain the question of whether or not the data can be decrypted without entering the user's password, when they are not logged in. I think that's one of the things you're planning to test. I think it cannot (short of actually cracking the encryption). I think the key is not stored in cleartext but must itself be decrypted using the user's password.

@Videonauth I think it's encrypted, and the user's password decrypts it. Doesn't resetting a password from recovery mode (or chrooting from a live environment to do it) cause the user's encrypted home directory, if they have one, to become inaccessible to them, such that special steps are required to decrypt the key using the old password? That was my understanding. Do we have a question for this on the site?

@Videonauth Understood.

Though arguably unclear, I think we should just dupe this question to both the suggested originals. One or the other (or both) almost certainly apply to the OP's situation, and to that of anyone who finds that question by searching.

Although I wish this question contained a more detailed description of what the OP did, I don't think we should close it. I would consider the top comment to be a possible answer; I've replied to suggest the commenter post one.

this is what im actually trying but i guess without digging deep into how pam works and checking what encryption method is used it might be hard to crack that and even if you have the insight it might be impossible nearly

i could try to install jhon and give it a go to crack it but i guess this might take days even if i have here chosen a rather simple password

you surely could try to brute force it

unless you have setup pam and apport in a way which would lock your account on serveral fals trys

and since there is nearly no latency you could run a really large amount of tests per second

or i could run a keylogger as a service and simply wait till user no1 logs in to see his password then a simple su mainuser would ask me for even that passwrod and i would be in

since i have sudo this should be not really a problem to inplement that

I'm not too worried about how crackable the encryption is, for the purposes of that answer. You could mention the possibility of cracking and keyloggers in an updated comment (or in an edit, if that seems appropriate) but I think that, if the user's password is needed even for root to access the cleartext of a user's encrypted files that the user has not actually themselves decrypted by logging on, then the basic method in that answer is sound, and it just needs warnings added.

Especially about how new user accounts' home folders aren't encrypted by default even if the first user's was... On the other hand, if that is possible without knowing the user's password, cracking keys, or waiting for the user to log in, then the basic method in the answer is probably at best of minor benefit.

as you can see i now pretended to have gotten the other users password via keylogger

su user was enough from my testuser out to get into it

and unless they run a ton of antivirus stuff a keylogger would not be detected

adn the testuser is only in the sudo group, none else

but he could leverage this to get malicious

all comes down to "if i have physical access, youre hosed anyways"

and if i can pretend to be your buddy and dont give you any reason to suspect anything bad, your data is not save

will write an according comment now

So, as I said I conducted some tests. Outcome: If you select encrypted home at installation, the main user home will get encrypted, additional user homes will not get encrypted by default. Simple sudo su <username> is not enough to get the other users directory decrypted, however as long this second user is in the sudo group he could easily set the logging accordingly or install a keylogger to get the other users password. Then a simple su <username> with the other users password is enough to decrypt his directory. — Videonauth27 secs ago

I do think this is providing meaningful security, though. Not a lot of security, but more than nothing. There are varying degrees of access to physical hardware. If Alice has the ability to obtain Bob's secrets, but she has to undertake specific action to achieve this, which doesn't work until then Bob subsequently takes action, that's different from Alice just being able to type one command and instantly access Bob's secrets.

We have all sorts of security measures that can be defeated with full access to physical hardware. Virtual consoles and display managers are configured by default to require that users log in with their passwords. Users with the power to run commands as root with sudo by default must enter their passwords again to run commands as root, even though of course either full physical access or just access to run non-privileged commands as that user are sufficient to capture their password.

The list goes on and on. These things aren't worthless. "Not worthless" means something, considering how many precautions people take in the name of security that actually are totally worthless, like allowing a user to only run a few commands as root... but one of them is vim.

@Zanna Maybe. Though the detail about how the initial shell used in WSL isn't a login shell is somewhat important to that question. One should pretty much never set a prompt directly in a file like ~/.bash_profile, though, and for that I'm sure we have something else.

Sorry about the extended messages about the encryption stuff, I get kinda carried away when it comes to encryption and cyphers, this is simply a topic I'm so highly interested in that i even tried to re-implement the software behind the newer encryption methods. :)

@Videonauth I think it's fine. If later it seems too much to keep here, they can go to the Island. This is all a big gray area anyway, since the messages are about improving content on the site, so they're not really off-topic for the Downboat, so much as they have the potential to become drawn out and highly technical. The same logic of replies would be retained if they were moved (they were interspersed with the Bash messages here anyway, after all). But it may be unnecessary to move them.

That is, after all, what the site is for. I mean, I don't want to minimize the importance of questions and answers, which are the form technical content is most useful in here. But the whole point of cleanup is to support that, not the other way around. Answers don't exist so reviewers can feel useful, or even to be voted on.