I am using Ubuntu 16.10.
I was following along a book, doing something like this:
#include <stdio.h>
int main() {
printf("Real UID:\t%d\n", getuid());
printf("Effective UID:\t%d\n", geteuid());
}
And to run this file as sudo without using the sudo command, after compiling with gcc, I changed the owner and group to root.
$ gcc -o test test.c
$ sudo chown root:root ./test
$ chmod u+s ./test
$ ls -l
-rwsr-xr-x 1 root root 8512 Mar 9 test
Now, this is what I got when I executed the file. My UID is 1000.
$ ./test
Real UID: 1000
Effective UID: 1000
The book I was reading said the result should be like this:
$ ./test
Real UID: 1000
Effective UID: 0
The UID for root is 0, right? Does this mean that I am running an -rwsr-xr-x file, owned by root, with my own user privilege? I don't understand.
Is your book a little on the older side? It seems like modern *nix variants widely ignore the sticky bit on executable files:
[...] the Linux kernel ignores the sticky bit on files. [...] When the sticky bit is set on a directory, files in that directory may only be unlinked or renamed by root or the directory owner or the file owner.[4]
https://en.wikipedia.org/wiki/Sticky_bit
Related
I am learning C from a book. The book mentioned archive files:
An archive contains .o files
Ever used a .zip or a .tar file? Then you know how
easy it is to create a file that contains other files. That’s
exactly what a .a archive file is: a file containing other
files.
Open up a terminal or a command prompt and
change into one of the library directories. These are
the directories like /usr/lib or C:\MinGW\lib that
contain the library code. In a library directory, you’ll
find a whole bunch of .a archives. And there’s a
command called nm that you can use to look inside
them.
However When I looked up the lib location(on Ubuntu) that book says, didn't find archive files.
How can I see these archive files?
The location of system libraries could change slightly across different distributions. On Ubuntu, you can find the static libraries in /usr/lib/x86_64-linux-gnu and /usr/lib32 for 64-bit and 32-bit respectively (This is, in fact, slightly different in older Ubuntu distros. But on recent distros (>Ubuntu 12), this has been consistent).
It depends on the software packages you have installed.
For example, if you install traceroute, then you should see something like this in /usr/lib/:
# ls -l /usr/lib/*.a
-rw-r--r-- 1 root root 22448 Aug 29 12:45 /usr/lib/libsupp.a
You can easily make your own library. For example:
mylib.c
int hello()
{
return 1;
}
test.c
#include <stdio.h>
int hello();
int main()
{
printf("Hello returned: %d\n", hello());
return 0;
}
Execute:
$ cc -c -o mylib.o mylib.c
$ ar r mylib.a mylib.o
$ cc -o test test.c mylib.a
$ ./test
Hello returned: 1
I'm running Linux Mint 14 with qemu, qemu-user, and the gnueabi toolchain installed. I compiled test.c with arm-linux-gnueabi-gcc test.c -o test.
When I try and run qemu-arm /usr/arm-linux-gnueabi/lib/ld-linux.so.3 test
I get an error saying: test: error while loading shared libraries: test: cannot open shared object file: No such file or directory. Running qemu-arm test, as I've previously tried, gives /lib/ld-linux.so.3: No such file or directory
However, the file does exist and is reachable.
$ stat /usr/arm-linux-gnueabi/lib/ld-linux.so.3
File: `/usr/arm-linux-gnueabi/lib/ld-linux.so.3' -> `ld-2.15.so'
Size: 10 Blocks: 0 IO Block: 4096 symbolic link
Device: 801h/2049d Inode: 4083308 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-04-22 16:19:48.090613901 -0700
Modify: 2012-09-21 08:31:29.000000000 -0700
Change: 2013-04-22 15:58:41.042542851 -0700
Birth: -
Does anyone know how I can make qemu run an arm program without having to emulate an entire arm Linux kernel?
test.c is
#include <stdio.h>
int main() {
printf("this had better work\n");
}
and file test is
test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=0xf2e49db65394b77c77ee5b65b83c0cc9220cbfc0, not stripped
you can run the example by providing a path to the arm-linux-gnueabi shared libs using the -L flag.
qemu-arm -L /usr/arm-linux-gnueabi/
also make sure the LD_LIBRARY_PATH is not set.
unset LD_LIBRARY_PATH
$ export QEMU_LD_PREFIX=/usr/arm-linux-gnueabi
This works for me.
It's basically the same thing as:
$ qemu-arm -L /usr/arm-linux-gnueabi/
You can add it to the ~/.bashrc file so you don't have to type it everytime you open the terminal.
I also met this problem when running a C program with assembly code. My solution is to build the executable with the option "-static", for instance
arm-linux-gnueabi-gcc -static -g main.c square.s
Then
qemu-arm a.out
will not report the error saying "can not find the /lib/ld-linux.so.3".
The only drawback is that the executable could be with a large size. But it's helpful when you just want to test your code.
Of course, you can go with the method from Balau(see artless noise's answer). But if you don't want to feel frustrated by something like "UART serial ports" in this step, which is only to run a simple "test" function, go for a try of my fix.
I solved the problem by copying the following libraries into /lib but I believe there should be a way better solution rather than this nasty solution I invented!
sudo cp /usr/arm-linux-gnueabi/lib/ld-linux.so.3 /lib
sudo cp /usr/arm-linux-gnueabi/lib/libgcc_s.so.1 /lib
sudo cp /usr/arm-linux-gnueabi/lib/libc.so.6 /lib
Please let me know if there are other better solutions as I am interested to know.
If you want to run ARM without Linux, then you need a different compiler (at least). arm-linux-gnueabi-gcc is a compiler for Linux. The compiler and libc are intimately linked. You will need a newlib compiler with a portability layer for qemu.porting newlib
See: Balau and Google newlib+qemu. A newlib port is hosted at Github and seems to the same as the Balau blog.
Typically a non-Linux gcc is called arm-none-eabi-gcc. The prefix arm-none-eabi- is recognized by some configure scripts.
A variant, which worked for me, was to pass the loader library directly and to specify the required library paths using the loader parameter --library-path. For example:
$ TOOLCHAIN_ROOT=/usr/local/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/arm-linux-gnueabihf
$ qemu-arm $TOOLCHAIN_ROOT/libc/lib/ld-linux-armhf.so.3 --library-path $TOOLCHAIN_ROOT/libc/lib/arm-linux-gnueabihf:/$TOOLCHAIN_ROOT/lib ./my_executable
Or equivalently export LD_LIBRARY_PATH instead of using --library-path.
I've compiled my C source using cc test.c, and it did generate a.out file.
However when I run it I get this error -
bash: ./a.out: Permission denied
My source is not in the home directory, it is on different FAT-32 partition, so I've mounted the drive in which the code is using the following command -
$ udisks --mount /dev/sda7 --mount-options umask=022
Mounted /org/freedesktop/UDisks/devices/sda7 at /media/48E9-FD53
$ cd /media/48E9-FD53/C
Then I compile my code using cc
I've also tried gcc. But still I get the same error.
Then I did - chmod +x a.out, still the same problem. Also with(chmod 755 a.out) and chmod u+x a.out.
I've also tried compiling and executing the program using sudo.
I've also tried - sudo chown sannidhya:sannidhya a.out.
I've tried every thing that I found after googling, still couldn't get it to work.
How can I run .out file (without moving it to home directory)?
Note - I am using Ubuntu 12.04 LTS.
But a weird thing here is, even after running chmod +x a.out, on running - ls -l a.out, I get-
-rw-r--r-- 1
also when I check the properties of a.out, under Permissions tab, when I check Allow executing file as program,the tick appears and quickly disappears.
Seems that you've mounted the partition with with no-exec flag set. You'll have to remount the partition:
sudo mount -o remount -o exec /dev/sda7
I'd guess you are doing all of this on an NTFS/FAT partition that you probably share with windows. chmod permissions do not work on them.
You should move it to an ext4 (or equivalent linux) partition, and then perform permission changes.
Else, for an NTFS/FAT partition, you set permissions for the entire partition, at the time of mounting.
For example,
sudo umount /mnt/my_partition
sudo mount -t vfat -o rw,auto,user,fmask=0000,dmask=0000 /dev/sda7 /mnt/my_partition
This would give you 777 on all directories and files (eeeek!), but once set, you can't modify them till you remount.
Here is another way to do it using fstab
cat /etc/fstab
LABEL=cloudimg-rootfs / ext4 defaults 0 1
D: /mnt/d drvfs defaults,user,metadata,exec 0 0
For some reason one of my directories has started producing
executables. By this I mean that new files in that directory are
a+x (but not, for example in the parent directory):
$ ls -ld .
drwxrwsr-x 2 me me 45 Dec 5 10:22 ./
drwxrwsr-x 10 me me 13 Dec 5 10:22 ../
$ rm -f test
$ touch test
$ ls -l test
-rwxrwxr-x 1 me me 0 Dec 5 10:25 test*
$ cd ..
$ rm -f test
$ touch test
$ ls -l test
-rw-rw-r--+ 1 me me 0 Dec 5 10:26 test
Also, notice the + at the end of the second permissions line, is it significant?
I know it cannot be a umask thing...but it's set at 0002.
How can I turn off this behavior?
EDIT:
In response to an answer below I ran the following (in the parent dir):
$ touch test
$ getfacl test
# file: test
# owner: me
# group: me
user::rw-
group::rw-
mask::rwx
other::r--
Why do I have this mask? Is this the right value for it? How can I change it?
The + indicates the presence of one or more ACLs on the entry. getfacl test will show you more information. The oddity with the apparent executability of new files may be related to the ACLs in the parent directory, but we'd have to see what they are to know for sure...
I would like to create an executable of my two mycode.c and my main.c, how can I create an executable? i did
gcc mycode.c main.c
and it generates a a.out, but when i click it it would not run.. (i am new to this so please bear with me)
Thank you
Try this
gcc mycode.c main.c -o myprogram
Then run ./myprogram
If you double click it you probably won't see anything, you should instead try running it from the command line, where you compiled it from in the first place.
Your a.out might not be executable yet.
do:
$> chmod 755 a.out
or
$> chmod a+x a.out
then try running it:
$> ./a.out