I have this C program:
#include <sys/stat.h>
#include <stdlib.h>
int main(void) {
if (chmod("/tmp/foo", 0755 | S_ISGID) < 0) {
exit(1);
}
exit(0);
}
When I run it like this:
rm -f /tmp/foo &&
touch /tmp/foo &&
./a.out &&
ls -al /tmp/foo &&
a.out runs with exit code 0 but the output is:
-rwxr-xr-x 1 philipp wheel 0 Mar 16 06:58 /tmp/foo
Why is the groupid flag not set here? The permissions should be -rwxr-sr-x.
The following things would fix the issue (but I still wonder why I see this effect):
running the program as root
running it in a different directory
running it on Linux
setting the set-user-id (S_ISUID)
I can swear it worked in an earlier version of OSX
What I tried but didn't work:
chmod g+s /tmp/foo also doesn't work
disabling csrutil did not change anything
altering the permissions on /tmp/ to something different, e.g. 0777 or 4777
So the question remains: what does make /tmp/ different from the other directories if it's not the permissions? The only difference I could see is:
ls -al /
showed tmp as this:
lrwxr-xr-x# 1 root wheel 11 Dec 11 19:28 tmp -> private/tmp
The # sign at the end shows that there are some non-unix properties set on the directory. Querying those with ls -l# /tmp shows:
lrwxr-xr-x# 1 root wheel 11 Dec 11 19:28 /tmp -> private/tmp
com.apple.FinderInfo 32
com.apple.rootless 0
Update: According to comment feedbacks and a downvote I figured the question is confusing, so I totally revised the question and the title. During revision I found out that I wrongly compared the effects of my program against chmod u+s which was wrong, I need to compare against chmod g+s, I also corrected this in my question.
The chmod() system call sets the permissions on a file to only the value you provide. This means that setting permissions to S_IRUSR | S_ISGID clears all other permissions, including user write and execute.
What you probably want is:
chmod("/tmp/foo", 0755 | S_ISGID);
(0755 being the octal mode for user read+write+execute and group/other read+execute -- it's a lot less typing than the equivalent constants.)
Related
Downloaded from here
Untarred, mkdir build, mkdir PC, executed...
../../gdb/configure --target=arm-linux-gnueabihf
returned...
../../gdb/gdbsupport/common-defs.h:33:10: fatal error: ../../gnulib/config.h: No such file or directory
#include "../../gnulib/config.h"
There was a 'gnulib' package I could install, installed it and it made no difference
Edited ../../gdb/gdbsupport/common-defs.h and found one header include based on gdbserver/gdb.
#ifdef GDBSERVER
#include "build-gnulib-gdbserver/config.h"
#else
#include "../../gnulib/config.h"
#endif
Go back two levels and there is a gnulib directory but no config.h, ll shows
-rw-rw-r-- 1 user user 51507 May 23 15:10 aclocal.m4
-rw-rw-r-- 1 user user 2417 May 23 15:10 ChangeLog
-rw-rw-r-- 1 user user 69989 May 23 15:10 config.in
-rw-rw-r-- 1 user user 743485 May 23 15:10 configure
-rw-rw-r-- 1 user user 1625 Feb 8 05:49 configure.ac
drwxrwxr-x 5 user user 4096 Jun 2 14:53 import/
-rw-rw-r-- 1 user user 739 May 23 15:10 Makefile.am
-rw-rw-r-- 1 user user 58332 May 23 15:10 Makefile.in
drwxrwxr-x 2 user user 4096 Jun 2 14:53 patches/
-rw-rw-r-- 1 user user 249 Sep 20 2019 README
-rwxrwxr-x 1 user user 5641 May 23 15:10 update-gnulib.sh
So in the process of writing out the end of my question I put two and two together and am just answering so no one else has to go through this.
As you'll notice configure in gnulib is not executable, so first I ran 'chmod +x configure' Before running it I figured I would go back into my build/PC directory to run configure from there to see if that would recursively configure gnulib, but that did not seem to be the case. You will need to execute ./configure inside of the gnulib directory to generate the config.h. I think regardless of you cross compiling or not you want gnulib to NOT have an explicit target, looks like it'll be used solely for the purpose of building GDB.
After running ./configure you'll now notice you have a config.h, yeahhhhhhh! Now go back to your build/PC directory and run make. Guess what? It will now complain about having already configured the gnulib directory and you need to clean up for make to work. "But Joe!", you say, "Won't that remove the config.h we so desperately needed?" "Yes! Yes it will!" So you need to move your config.h elsewhere, execute 'make distclean' inside of the gnulib directory, go back to your build directory, just wipe it out completely because you'll have issues due to the mixed configurations, re-configure yet again, DON'T FORGET TO COPY CONFIG.H BACK INTO GNULIB/, then run make.
All in a days work.
This is a repost after being referred to "Calling a script from a setuid root C program - script does not run as root" for a solution
My problem is different in that I do not want to run the C program (and c-shell script called inside) as root. Rather, I want to run as the owner of the c program file.
Also, I tried with "setuid(0)" as this was the solution in the referenced post. This is reflected in the edited code below. Same results.
Also, I opened permissions up all the way this time with "chmod 7775" (just in case it was a permissions problem)
Here's the original note with edits to reflect the change to "setuid(0)"
I'm having a problem implementing an simple example that would demonstrate how setuid can be made to run a binary with the uid of the file owner of the binary. What I would eventually like to do is run a c-shell script using this technique.
I read that this will not work for shell scripts but also heard of a work-around using a C program to run a system() call that'll run the c-shell script ( e.g. system("source my.csh") ). I wrote a C program that attempts this, plus simply reports the current uid. This is what I tried...
From my current shell, I did a "su katman" to become the user of the binary I want to run as user katman.
I created a C program try.c. ...
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
setuid(0);
printf("In try.c ... sourcing katwhoami.csh...\n");
system( "source /home/me/su_experiments/katwhoami.csh");
printf("In try.c ... using straight system call...\n");
system("whoami");
return 0;
}
I "setuid(0)" as recommended by a reference to a different note. But earlier, I tried setting it to the uid of the C program's owner as obtained with "id -u".
The katwhoami.csh shell script is simply...
date
echo "In katwhoami.csh, I am "`whoami`
echo "In katwhoami.csh, I am "$USER
exit
Then I compiled the C program and set the bit...
% gcc -o try try.c
% chmod 7775 try
% ls -l try
-rwsrwsr-x 1 katman design 6784 Mar 1 11:59 try
And then I test it...
% try
In try.c ... sourcing katwhoami.csh...
Thu Mar 1 12:28:28 EST 2018
In katwhoami.csh, I am ktadmin
In katwhoami.csh, I am ktadmin
In try.c ... using straight system call...
ktadmin
...which is what I expected.
I exit to get back to the shell I started from, hoping that if I run try there, it'll tell me I'm "katman"....
% exit
% whoami
daveg
% try
In try.c ... sourcing katwhoami.csh...
Thu Mar 1 12:30:04 EST 2018
In katwhoami.csh, I am daveg
In katwhoami.csh, I am daveg
In try.c ... using straight system call...
daveg
... which is not what I was hoping for :-(
As you can probably tell, I'm new at using this.
Any help would be appreciated !
Update....
I tried a new sample program, a.c...
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
FILE *fh;
setuid(1234);
system("whoami");
fh=fopen("test.file","w");
fprintf(fh,"Here I am\n");
fclose(fh);
return 0;
}
I compiled and set the bit
gcc -o a a.c
chmod 4775 a
Then I exited the "su" and ran as a user that is NOT the owner of the binary. Same result as before with regard to reported uid (the current uid), BUT, the owner of the file that the C program created ion this version was the owner of the C program !!! So that worked.
Is there something fishy about the "whoami" command? system() call ?
If I do a "system("source some.csh") does it create a new shell which assumes the original uid (not the owner of the C binary) ? Something like that ?
I really need the new uid to "stick" as far as child processes.
Hi i want to install MinorFS 0.3.5 to my computer. My Ubuntu version is 14.04 LTS. But i had some problems while installing the program.
Firstly i installed all fuse modules and gcc and run the script install.pl.
The program is designed for Ubuntu 8. As a result it wants to install fuse module to start the script install.pl.
But there is not a loadable fuse module for Ubuntu 14.04 LTS. I research about it and i see that, for the latest version of Ubuntu, the kernel is configured to include FUSE instead of compiling it as a module. So, i modified the perl code in install.pl and
install the script.(I install fuseiso with command apt-get install fuseiso just in case.)
Everyting is great for the moment. But for the next step, i run the command on terminal "/etc/init.d/minorfs start ".
And i get this error : " The path specified in /var/minorfs/viewfs.startcap is not a valid base dir for minorviewfs
"
This command runs the minorcapfs and minorviewfs i guess.Minorcapfs run succesfully but for minorviewfs i got this error.
The code which gives the Error writen below:(in minorviewfs file)
unless (-d $basepath) {
print STDERR "The path specified in $VARDIR/viewfs.startcap is not a valid base dir for minorviewfs\n";
exit 1;
}
Then for test, i print my " $basepath " and it's : /mnt/minorfs/cap/61ce0488ac06eba530e178a0d1716ec576b47f71
I couldn't solve this error.
Please help me to get rid of this problem.
Thank you!
I solved the problem with manually making a directory with the mkdir command. Now the script work. But now I have a different problem. The output is ;
Starting MinorFs filesystems minorcapfs going into background, consult syslog for information minorviewfs going into background, consult syslog for information.
Then when i run the command ls -la /mnt/minorfs/priv
i should get a links to the folders. But I have nothing.
dr-xr-xr-x 1 root root 0 Jan 1 1970 .
lrwxrwxrwx 1 root root 0 Jan 1 1970 home ->
lrwxrwxrwx 1 root root 0 Jan 1 1970 tmp ->
So i looked the system log file with gedit /var/log/syslog and i see that Error;
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: Problem in Fuse::main at /usr/local/bin/minorcapfs line 340
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: user: 0 1001 ; group 104 104 104 104 at /usr/local/bin/minorcapfs line 341
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: Probably a problem accesing /dev/fuse at /usr/local/bin/minorcapfs line 342
Sep 1 13:52:01 burak-UX31A minorviewfs[3584]: Use of uninitialized value in subroutine entry at /usr/lib/perl5/Fuse.pm line 147, line 26.
And this the MinorCapfs code ; http://codepad.org/nUUJ3b5m
How to get rid of this problems? Thank you.
For some reason i am not able to attach to my very own processes?! Works fine if i try strace as root.
$ ./list8 &
[1] 3141
$ child4 starts...
$ strace -p 3141
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
$ cat /proc/sys/kernel/yama/ptrace_scope
1
Running on lubuntu 13.10
Linux goal 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:19:42 UTC 2013 i686 i686 i686 GNU/Linux
So then how does gdb attach to user's own processes without having to muck around with kernel settings (ptrace_scope)??
Looks like you answered your own question -- you have ptrace_scope set to 1, so you can only trace direct children. To allow tracing any process belonging to the same user, set it to 0. This is also required to use the gdb attach command.
READ the /etc/sysctl.d/10-ptrace.conf file as your error message suggested...
If strace fails as root, try checking whether... gdb or strace is not running in the background (that was my case).
Command: ps aux | grep "gdb\|strace"
If this fails as root, I had a problem stracing enlightenment (e17) and the reason was that you can't strace a process already being straced or run under gdb, which some programs will do so that they can get their own debugging info.
I'm trying to use a somewhat old DAQ, and had to jump through a few hoops to get an old (circa 2004) device driver for it to compile (DTI-DT340 Linux-DAQ-PCI).
I've gotten to the point where it compiles, I can load the kernel module, it finds the card, and I can create the character devices using mknod.
But I can't seem to open these devices and keep getting errno 19 (ENODEV) 'No such device' when I try to
open("/dev/dt340/0",O_RDWR);
but mknod had no complaints about making it, and it's there:
# ls -l /dev/dt340/
total 0
crw-rw-r-- 1 root staff 250, 0 2009-04-23 11:02 0
crw-rw-r-- 1 root staff 250, 1 2009-04-23 11:02 1
crw-rw-r-- 1 root staff 250, 2 2009-04-23 11:02 2
crw-rw-r-- 1 root staff 250, 3 2009-04-23 11:02 3
Is there something I'm neglecting to do? What might be a reason open fails?
Here's the script I use to load the driver and make the devices.
#!/bin/bash
module="dt340"
device="dt340"
mode="664"
# invoke modprobe with all arguments we were passed
#/sbin/modprobe -t misc -lroot -f -s $module.o $* || exit 1
insmod $module.ko
# remove stale nodes
rm -f /dev/${device}/[0-3]
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
mkdir -p /dev/${device}
mknod /dev/${device}/0 c $major 0
mknod /dev/${device}/1 c $major 1
mknod /dev/${device}/2 c $major 2
mknod /dev/${device}/3 c $major 3
# give appropriate group/permissions, and change the group
# not all distributions have staff; some have "users" instead
group="staff"
grep '^staff:' /etc/group > /dev/null || group="users"
chgrp $group /dev/${device}/[0-3]
chmod $mode /dev/${device}/[0-3]
Some additional info:
#grep dt340 /proc/devices
250 dt340
# lsmod | grep dt340
dt340 21516 0
# tail /var/log/messages
Apr 23 11:59:26 ve kernel: [ 412.862139] dt340 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Apr 23 11:59:26 ve kernel: [ 412.862362] dt340: In function dt340_init_one:
Apr 23 11:59:26 ve kernel: [ 412.862363] Device DT340 Rev 0x0 detected at address 0xfebf0000
#lspci | grep 340
03:01.0 Multimedia controller: Data Translation DT340
ANSWER: A printk confirmed that the -ENODEV was thrown from inside open(). Following an oldstyle
while ((pdev = pci_find_device(PCI_VENDOR_ID_DTI, PCI_ANY_ID, pdev)))
(which is deprecated), if(!pdev) ends up true, and returns the -ENODEV.
I'm inching closer - I guess I have to work through and update the pci code to use more modern mechanisms...
If the device shows up in /proc/devices, and you're sure you've got the number right in mknod, then the driver itself is refusing the open. The driver can return any error code from open() - including "no such device", which it might if it discovered a problem initialising the hardware.
I'd guess it is a problem in the driver, check the open function.
It shows up in /proc/devices, so all the generic device stuff seems to be ok.
mknod doesn't care if there is an device corresponding to the given major/minor numbers. Are you sure insmod is installing your module? What does lsmod tell you?
I'm unfamiliar with having to add the ".ko" extension. Is that something specific to your device driver?
Check through lspci and make sure hardware is properly initialized. If your system supports hotplug, pci_find_device won't work. The problem with this is a refcnt. The best way to deal and learn is to dissect the API. BOL !!