Forgot my username

Z

Zytdar

Guys please help! I forgot my admin's username... How to found it without loggin in? (and also without reinstalling the system)
 
Well, you have one option - boot with freebsd livecd or liveusb, mount your filesystem somewhere and then nano your_mountpoint/etc/passwd . You will be able to find your login there.
 
during boot, go single user.
This is usually an option on the menu, or you need to press "any key" during the boot timeout. If this is the case type "boot -s" at the prompt.

Press enter for /bin/sh, and type
Code: 
 cat /etc/passwd | fgrep '1001'
if it was the first user on the system
or type
Code: 
 less /etc/passwd
and browse for a user with a home directory under /usr/home
 
If there were a password for single user, all it would take is a FreeBSD boot memstick and changing the tty to secure, or however the password was implemented. Or simply reading /etc/passwd from the memstick.

From the OpenBSD SASQ (forgive me!)

"If an attacker has physical access to your system, they win, regardless of the OS on the computer. There are ways to force the use of a password on single-user mode (see ttys(5)), or eliminate the pause on i386/amd64 (see boot.conf), but practically speaking, getting around those tricks is also pretty easy (One way: boot floppy or CDROM, edit or replace password file). You can try to prevent that, but then someone will pull the hard disk out of your computer. Making your computer difficult to manage properly isn't real security, and if you don't have the physical machine secured, you have no real security."

Encryption is the *RIGHT* answer if you want to make it harder for physical access to yield sensitive information, but it too can be defeated in certain cases.
 
Well, the only thing that one can reach on collocation where all servers physically protected with private cage without asking datacenter's personal to open a cage - it is a keyboard. To protect server from "over-smarted" neighbors it is more than enough (IMHO) to
Code: 
echo 'password=SuperDuperCocaColaPasswd' >>/boot/loader.conf.local
to protect to load someones server to single user mode.
Of cause any single password base solutions can be easily cracked with help of torture :) but there is also solution against them - "Shamir's secret sharing scheme" :)
 
Zytdar said:
Guys please help! I forgot my admin's username...
Click to expand...
It's root. FreeBSD doesn't really have a concept of "admin" users. Are you sure this isn't an OS-X question?
 
FreeBSD "admin" users can exist!

A user in the group wheel or operator has abilities another user doesn't.
So does a user mentioned in /usr/local/etc/sudoers if sudo is installed.
ConsoleKit, although usually not configured much on FreeBSD because it is lame, can also grant privileges in a roundabout, non-POSIXy way.
A lot of ports recommend adding a user into a special group to get device permissions for usb, sound, video etc.
To me, any of the above could produce something I would call an admin user.

So although you are correct that the base system does not have a concept of an "admin" user, FreeBSD is not "root or nothing".

I assumed the original question was in regards to the first non-root interactive user, usually uid 1001.

If the goal is simply privilege escalation, then simply booting to single user and setting a password should work on either OS X or FreeBSD or Linux (well, used to be, now it's init=/bin/sh, but same difference).
 
m6tt said:
FreeBSD "admin" users can exist!
Click to expand...

Of course they can, but also root (and toor) are still there. So the point is that someone else should be able to log in in the machine as root and retrieve the lost username (and using gecos should be better than uid 1001, at least if the user creation was done with a little information required to know who is who).
 
Hi Fluca, please see post #3 where I recommended exactly the solution you mention (actually as single user, which is sometimes above root in some unixes).

Seems like we were on different wavelengths...My post regarding admin users was a response to SirDice, and was really just nit-picking about what an "admin user" is.

FreeBSD does not have an "admin" group like Mac OS X, which is essentially like being in the sudoers file. I think that is what SirDice was referring to, as "Admin user" is a special term in Mac OS X.

However, in FreeBSD, you can create more-privileged users or users who have permission to do things like su to root, or perform device IO, or run sudo. I assumed the original poster was referring to such a user, as I might call a more-privileged user an "admin" user since it's not a term "reserved" by the OS (like it is on Windows or OS X).
 
m6tt said:
FreeBSD "admin" users can exist!
So although you are correct that the base system does not have a concept of an "admin" user, FreeBSD is not "root or nothing".
Click to expand...

m6tt,

I'm sorry to interfere but I think what you're saying is not quite true... The concept "root or nothing" is with respect to the kernel, and yes FreeBSD's security model -as most other *NICes- is by default "root or nothing". If MAC or RBAC come into play, then this model changes indeed. But security/sudo and file permissions (even using POSIX ACLs) are not enough to change the way a traditional POSIX *NIX security model ("root or nothing" as you called it) operates.
 
Thanks Mamalos, your post was certainly thought provoking.
I'll try to clarify what I mean, although now that we know what Zytdar was looking for, it's quite moot.

I am *not* saying that any arbitrary user can be granted any root-like permission.

You are looking at only one facet of the traditional unix security model, and much of traditional unix security revolves around and is defined by access to files, pipes and devices. The first facet is indeed API level and is often root or nothing, although nothing in POSIX requires that exclusively. For instance Solaris is officially POSIX, and has a perhaps overly complicated RBAC. File permissions (standard, or ACL) are indeed a type of user privilege administered by the kernel, and dismissing them does not remove their importance whatsoever. Root is just a setuid away, anyway :).

Sure, I can't make my hypothetical "admin" user able to change network interfaces in the base system directly, but I can give him access to /etc and let him do many things indirectly, perhaps just permissions on the config file of a webserver he administrates. I could then give him permission to /usr/local/www, and allow him to administrate the contents of the web server he configured. Is he an admin? Yes. Is he some special POSIX creature, beyond a "user"? Absolutely not. Is the kernel letting him do things another user cannot? Yes.

We've essentially descended into semantics over the meaning of the word admin, and I ultimately retreat to the position (yours) that "admin" is not a defined role between user and root in the traditional unix security model. As a result it is "just" a word that could be used for one who has the privileges to administrate a system, whether they are root or user. Which is what I've been trying to say :)
 
Hi m6tt,

I had got your point even from the previous post, and I knew you meant "admin" in a specific way. This is why I was reluctant on posting my opinion, and this is why I excused myself on my post; I was afraid that we could start an endless-pointless conversation due to different points of view...

Yes, if we decide to dub admin someone that has other/more filesystem privileges than some other user, of course FreeBSD offers this functionality. But -I think you agree too on this- filesystem permissions are far more restrictive compared to MAC or RBAC frameworks, where access rights can be granted on network, memory and many other system resources as well. Moreover, root account on traditionally *NICES can do anything, which is not necessarily true on non DAC systems.

No need to move the post any further, I understand you are a knowledgeable *NIX user, I am only saying that some of your words could be misunderstood by some entry-level *NIX users, and they could cultivate a misconception with respect to the general *NIX security model.
 
You must log in or register to reply here.
Back
Top